"In my experience, men who respond to good fortune with modesty are harder to find than those who face adversity with courage." - said Cyrus the king of Persia.
In the field of software development, you will find more people who like building things from scratch than people who like to work on legacy code. Yet, you will find more developers who will actually work on maintaining code than programmers who build brand new applications. At least that’s my perception. I work in a big corporation so that’s kind of expected. Though, it might be different at smaller companies.
Anyway. Does this tell us anything about how people work on whatever type of projects they have? Not at all.
When you work on legacy code, you will find the following types of developers:
The copy-pasters. They are afraid. They are afraid of failure. They are afraid of peer pressure or their bosses. Maybe they just don’t care. They will do the least effort possible to fix an issue. If it means that they copy the same two lines to dozens of functions because they don’t want to create a new one, they will do it. They might break things because sometimes they repeat the wrong lines of code at the wrong place. But most likely they will rarely break your application. They optimized the way they work to avoid immediate software failures. What is sure, that thanks to them the code will become less and less maintainable, they will let the code rot.
Let’s call the second group apprentices. They are brave, but they lack experience, even knowledge sometimes, but the apprentices want to improve themselves and the code base they work on. Apprentices will extract till they drop if needed, they will create new functions, they will dare to reorganize code. They will add tests whenever they can. As they lack experience, they might not test the good thing. They might break the code, but they recognize that shit happens and the only people who don’t break things from time to time are those who don’t do anything. Depending on how persistent they are and what kind of environment they work in, they might end-up copy-pasters hating their own work, or they become masters.
The masters learnt to love working on a crap codebase in a supportive environment. They see big opportunities in turning shit not necessarily to gold, but to fertile soil. Masters will try to hold back the copy-pasters’ pull requests - almost every team has some of them. They will make serious efforts to educate them, to educate bosses, to educate anyone, especially the brave padawans. If they face too much negligence, they will eventually go to another team where change is welcome. When you really need them, they will appear because they look for a welcoming environment.
Now you might wonder, okay, here is this arbitrary and incomplete classification, but in the end who work on greenfield projects?
Of course the same type of people!
Is the distribution of these developers different?
I think so. In my opinion, it’s less likely that people will become masters working solely on greenfield projects. But why?
You will find the same copy-pasters and people who just don’t care about their craft. You will also find the same apprentices, who want to become better by learning and educating themselves.
The problem frequently is that in our fast-paced world these courageous developers with good intentions will not stay on the same code-base for a period of time that is long enough to see the effects of what they delivered.
It’s the next set of developers who will have to deal with the code they considered awesome. It’s the new developers who will have to face the memory leaks, the core dumps, the rigid structure, the premature optimization, the inadequate tests.
By the time these issues come up, the authors of that code will already work on the next project producing most probably better, but still suboptimal code quality. With a few notable exceptions of course. Keep in mind that this somewhat questionable code quality is still way better than what is produced by the copy-pasters.
Someone told a friend of mine who was looking for a new team that “writing maintainable code is nothing one can learn easily from a book or a training course at the corporation or the university. The best way to learn about it is to do it on an application that creates already value and to teach it to colleagues. ”
In his experience, men who respond to greenfield projects with careful design and with vigilant coding are harder to find than those who face legacy codebases equipped with proper refactoring techniques that they are willing to use with a whole heart.
This article has been originally published on my blog.
Top comments (4)
I think that's part of the reason why we have Expert Beginners. It's possible to go around creating one project after another, leaving behind a trail of unmaintainable "successes." I've seen it self-perpetuate. The first developer is obviously a rock star because he gets stuff done. The ones coming behind him are just okay or worse because it takes them much longer to add new features. A non-developer will never understand that their rock star is borrowing and everyone else is paying interest.
True. I know someone who recently spent quite some time fixing a bug. There was an untested ~600 lines long function checking the criticality of certain changes. There were bunch of
ifs in there with multi-line expressions. Sometimes on both sides of the comparison operator, there were the same expressions... It was full of bugs. It took him quite some time, I did the code review, I understand why... Then the project manager said that she doesn't understand why it took so much time, she used to be a C++ dev herself...A lot of this resonates with me. I don't work near especially large cities. So most of the apps I wrote were for smaller businesses who tend to make investments in app dev last a very long time. Last I heard, my very first professional PHP/MySQL app is still in use. Although I haven't touched that particular code in over a decade, I still have to maintain code I wrote in my formative years as a programmer. Code that makes me shudder. Code that led me to get interested in app and system architecture, because what I wrote was nearly always hard to maintain. I didn't feel I could stay a programmer if I continued to add more unmaintainable code, which I would subsequently fight again and again. Sticking around to reap the whirlwind has definitely affected how I go about development.
It also makes me cynical of the promises of new tech. Most new techs are just rehashes of the old tech with a slightly different emphasis and more conveniences. This shifts trade-offs but doesn't significantly improve maintainability in the long term. This was brought to mind recently by the post How components won the "framework wars".
That doesn't mean I have figured out the One True Stack, of course. These are just observations that tools and techs are not to be trusted as the answer to maintainability. People who think it through are, and especially when they have lived it before. Of course, I didn't have any such person available to teach me, so I did what research I could but learned a lot of it the hard way.
This reminds me of a code base. I used to work on an API that is widely used in my company. It's quite old, maybe 15-20 years old.
Once I had to look into a quite hairy part of it and I found it awful. Variables named
ps andqs all over the place in lengthy functions.I also found some copyright notes mentioning a guy who I already knew in the company but I had no idea that he had done development before. I had my own opinion that I obviously didn't share.
A bit later I read a relatively old book about C++ compilers. And while I was reading it, I realised that this guy didn't do anything bad. When he wrote the code, the length of variable names and the number of (virtual) function calls did matter.
The point is that if we read some old code and we find it unreadable, we shouldn't judge. Maybe that time it was the state-of-the-art, just times changed.
By the way that was far from being the oldest code... We decommissioned code coming from 70s just last year... Huge fun :D