Almost half of any Finnish generation goes through a shared experience: the conscript army. An integral part of that experience is learning military slang, a set way people in the army talk. The stories told with said jargon often spread outside of the barracks. It is not uncommon to hear strangers bonding together over beers reminiscing and feeling nostalgic about freezing cold nights spent in tents.
There is a similar phenomenon detectable among us coders. To be part of the coder tribe, there is at least one type of story that one must master. That is - of course - ranting about legacy codebases. "Can you believe how much of a mess the previous coders left? Hear, hear!" There is no better way to onboard a new team member than to blame some previous B-team for all the murky parts of the system at hand.
This can be seen as harmless, a subject for a good meme. Rarely do we hold real grudges against "the legacy folk" and can be the best of friends in a social gathering. Judging others, after all, is foundational to the human condition. Thousands upon thousands of both fact and fiction books and scientific publications explore the urge to feel superior over others. Besides, there is an obvious benefit. New, sometimes better ideas emerge, which can't necessarily be implemented in a legacy codebase.
Yet, this way of thinking has a toxic undertone. The new team members can develop a misguided sense of knowing how things should be done. And oh boy, are they confident they will make it right this time!
The fact is that the new A-team will end up just like the old B-team. Sure, they will improve the codebase and likely leave it in a better state. However, as the previous developers, they are equally helpless against the merciless churn of incoming tech, trends, and changing requirements. Even if they read all the relevant software architecture books, get the certificates, listen to the best experts, and produce a polished repository, the next team would either not recognize it or rewrite everything in a new framework in a few years.
There is a vicious cycle of us developers hating other devs who leave behind an apparent mess. We also dislike those who work with the wrong language, work in the wrong company, don't spend their free-time coding, are too nitpicky, are too opinionated, never have an opinion, are too talkative, are not chatty enough, and so on and so on. If only everyone fit the ideal 10x coder model, all software would turn out fantastic!
I'm not saying we should not be highly critical of the code we are working on. We all know that we quickly become blind to the faults of our beloved pet projects. That brings me to the point that it happens to all of us.
You, the reader, or I am not the super coder who never leaves a sub-par codebase or is never part of such a team. This is nothing personal but just statistics. If you see something horrible every time you pull a new repository and think I would have done much better, I've got some news for you. Depending on which point you are on your career path, you've left or will leave an equal amount of legacy behind you. The reason is simply that even the best examples of software design don't stay that way for long. That is just how the software development game plays out, so it is high time we start behaving accordingly.
Comments
Post a Comment