Software is a solved problem: most of the fundamentals were nailed by the early 1960s. Tech projects have highly educated and well-resourced teams. So why do so many projects degenerate into a mess? Like the spoiler from Soylent Green, the answer is "people".
Below, I've divided projects into two categories of failure, each with a distinct tragic flaw: the Hamlet and the Macbeth of software architectures. This is quite an arbitrary distinction, and projects can hit problems for a multitude of reasons. But these two recurring patterns reliably create a feeling of dread and actual nausea like no others I have encountered. They are not just "bad code", but pathological syndromes of some greater institutional illness. Please note that this is pure polemic, and I don't have any numbers to back up my observations. So, let's go!
Lifting the lid on this codebase releases wafts of mouldy carpet, printer toner, and cork ceiling tiles. This smells like Java; the cheap filter coffee of the 90s, and a stuffy corporate programming language of the same era.
The Enterprise Shitpile inherits (no pun intended) the stale overtones of the bureacracy which produced it: long, stuffy, meetings where nothing gets decided, and hazy business goals that address no real need, other than perpetuating their own existence.
Bad Java code is marked by a fetishisation of object orientation: everything revolves around classes and inheritance. Enterprise Shitpile code smells like the worst examples of early Java.
A closer look at this code reveals an archetypal Kingdom of Nouns: multitudes of classes which literally do nothing. They have long names like FactoryConnectorUtilityClassInterface. To understand a single function, you must follow a long line of empty inheritances, to find a tiny fragment of code that affects something in an indirect way on the other side of the codebase.
Premature abstraction is caused by developers without strong leadership. Psychologically, it arises from insecurity: from a fear of the future, and of making decisive architecture decisions.
Taking architecture leadership means taking assertive steps towards writing code that actually does something. For those who are too afraid to do this, the zero-risk option is to create an empty structure, immensely complex and monumental, but dead, motionless, and rigid. They can spend 90% of their time looking busy; writing code which looks complex, but does nothing. That's 90% of the time when they don't have to think about what they are doing, or putting their arse on the line by making some solid architecture decisions.
From the Alien: Covenant movie. Image from www.alien-covenant.com.
While indecision is the mother of the Enterprise Shitpile, hubris and megalomania is the mother of the Monster Breeding Lab.
Software developers literally run the world. We can make or break billion-dollar companies. That can be enough to bring out the mad genius in anyone.
Sometimes, when encountering an existing project, we lift the lid on a twisted kingdom of monstrosities. We find grotesque genetic hybrids, and strange malformed monsters conjured up by an unhinged mind. I know this, because I start sliding into weird coding habits myself if I don't get colleagues to reality check me and critique my work.
Maintaining and refactoring this code is a time-consuming nightmare, as the original developer hasn't considered the perspective of anybody coming after them.
This is usually the work of a single developer: a “goose who lays golden eggs”, who runs amok without audit, accountability, or organisational oversight. They may be effectively holding management hostage through the level of control and power they have over the business infrastructure, and the lack of transparency they have fostered in their code.
They may even consciously or unconsciously obfuscate code in order to render themselves irreplaceable, and keep sole dominance over their domain.
What does an evil genius do when they have total dominion over a project?
Everyone around you has spent a lifetime honing their specific skills. Get advice and listen to it; this is not a sign of ignorance, but of a willingness to learn and strive for the best result possible. Everybody on the team looks good when a project goes well - it's not a contest. Scribble and discuss over a whiteboard until a good solution is obvious to everybody.
Write for an audience. Tolstoy, Orwell, and Hemingway show that clear, simple writing is the mark of the true master of communication, and that pseudo-intellectual word salads are the mark of a mediocre writer. Always use the programming equivalent of Plain English (unless you are writing bare machine code, perhaps). Your code should explain itself like good literature.
Be lazy. Be stupid. This comes naturally to me. Look for the simplest, most obvious solution. Sometimes a simple imperative “for” loop over a dozen items is cleaner than a chain of map/reduce/filter operations or a convoluted SQL query.
When hiring: ask yourself if you would want to spend 8 hours per day, 5 days a week for the rest of your working life with this person? Do you imagine working next to them, bouncing ideas and designs off each other? In their job interviews, are they savagely disparaging and dismissing their old teams or ideas they don't agree with? Are they likely to wander off and do their own thing, regardless of what the business needs are?
Pair program. Some programmers respond to this request as if you'd asked them to cuddle in a jacuzzi with you. But it works. It's a great way to give your code the benefit of a second opinion, and to pick up new ideas while you are working. You know you really understand something properly if you can explain it.
We now have the technical means to do almost anything we can dream of on this planet. The only problems remaining in the world are organizational, political, personal, and social in nature. Let's try and address these along with the technical issues, so we can make things that work better, by working better together.
James Hudson
If you have any thoughts on this, please email me. Or at least "like" or "share" this post if you think others would appreciate it.
Needless to say, this blog isn't financial or legal advice, an excuse for getting fired, or promising that any of these ideas will work for you. The companies or people I mention may not agree with my opinions here. Don't do anything reckless, damaging or hurtful to anyone! In the future you might need your bridges unburnt. Images used under fair use, and are copyright their respective owners. (c)2014-2019 James Hudson