The software industry is an unusual beast. Unlike any other engineering domain I can think of, software development is judged almost entirely by the results, and not by the methods that go into producing the results. After all, to those who aren’t writing or maintaining the code, why should we care what the code looks like as long as it works? All of my UAT (User Acceptance Testing) tests pass? Great! I’ve got the software that I need. Simple, right? Well, no.
What would Brunel do?
Let’s borrow from another engineering discipline. A new bridge is needed to cross a river. What are the requirements of that bridge? Well, we need to be able to move people from point A on this side of the river, to point B on the other side and vice versa. Great, I give you… a catapult! I have met the requirements, everybody that needs to move to the other side of the river will get there! OK, so this one is a requirements problem, not an implementation quality problem. We need to add some requirements that the people arrive intact! OK, fine, plan B, I’ll lash some planks of wood together and balance them over the river. Great, the people can cross on the plank bridge, they arrive on the other side intact, my UAT of people crossing the bridge say that I’ve functionally achieved everything I set out to achieve. Alarmingly often, this is where the software industry seems to finish. What’s the problem with that? Well for starters, people need to keep crossing this river over and over again over a period of time. In two, three, four years from now people still need to be crossing this bridge. At some point the low quality construction materials are going to start to fail, and eventually collapse into the river.
Clifton Suspension Bridge (Brunel)
OK, I’ll stop flogging my bad analogy now. My point is this: the software industry needs a culture shift. The expectations and incentives in place mean that - with depressing regularity - I see people opting for the quick fix, choosing to apply the awkward patch, and looking for the result that shows them the functionality that they needed yesterday, irrespective of the longer-term consequences. I’ve also seen many software developers who are great at functionally finding a way of meeting the requirements, but who seem to have no understanding of the maintenance issues that they are introducing into the code due to poor coding practices. This is the crux of the reason why I see this as a cultural issue. All of these developers are capable of writing high quality code, but culturally there seems to be no appetite or incentive to push for it. The pressure is on to deliver NOW, but very little incentives to take the extra time to do things properly.
The real cost of low quality code
I did some research in an attempt to back this up into something more than just a rant; what really struck me about the research was that there are many resources on what defines high quality code, but precious little giving hard evidence on the impact of code quality issues. A few papers existed giving some statistics about lifespans of software products and some probable link to code quality, but the evidence gathering was pretty scant and largely anecdotal. If I was to put bad code on trial today, I wouldn’t have enough evidence to convict, and yet I’ve seen it for myself on numerous occasions. Large scale systems whose maintenance slowly costs more and more. Seemingly straightforward feature requests taking longer and longer to develop, and costing more than expected due to reports of “unforeseen complexities”.
Tell me you don’t recognize these symptoms? I’ve had first-hand experience of digging into and debugging these sorts of issues to see quite clearly where the poor coding practices, and development short-cuts have directly lead to the situation that made the bug so much more difficult to diagnose and fix, so it’s baffling to me that so little research seems to exist to illustrate this link.
Bad legacy code...
I can’t help but think that the software industry is burying its head in the sand and pretending the problem doesn’t exist. After all, a prevalence of buggy, expensive to maintain software systems means there is more work around that relies on the industry, right? A cynical viewpoint, perhaps, but my challenge to the software industry is: prove me wrong. My challenge to the many industries and companies that rely on software is a more complex one: try to avoid the trap of short term-ism. A bridge built using best practise and high quality materials is going to cost you more than buying some planks of wood lashed together… but you aren’t comparing like for like. The planks of wood lashed together may give you the same end result for a short period, but you are soon going to be spending more money on repairing the deterioration, and/or replacing the whole thing all over again.
What would Ghyston do?
I’m lucky enough to work for one of the few companies in the industry who have a high quality culture, but I see no reason why that should be the exception, rather than the rule. I believe the industry (and indeed all of the dependant industries that have software requirements) would benefit from adopting the same culture.
Ghyston (The blonde one)
So, to come back to my original question, why should I care about code quality? Well, it depends who you are.
- If you’re a software developer, you should care because sooner or later somebody just like you is going to be reading and updating this code; and sooner or later you are going to have to start updating some code that was written by your peers. The more effort that has been put into maintaining the standards of the code previously, the more quickly you are going to be able to go back to your manager/customer and give them a good result. The less time we all spend solving issues caused by low quality code, and banging our head against poor design, the more time we all get to spend solving interesting problems, writing something new and interesting, or, heaven forbid, leaving work at a sensible hour!
- If you are an IT manager with a software budget, you should care because you want your system to still be working for you in 10 years or longer, rather than 2. You should care so that the teams delivering software to you (whether internal or outsourced) are giving you value for your money. You should care so that those same teams aren’t going to have you held hostage by spiralling bills to maintain it.
- If you are a user of the system, you should care because you’ll encounter far fewer application crashes, and other failures. You should care because you’ll be able to carry on using the same, familiar system for longer into the future. You should care because you’ll be much more likely to get those additional features that improve your day to day use of the system.
My dream is a software industry that cares about quality. An industry in which my default reaction on encountering a new code base that I’m going to be maintaining is not one that makes me die inside… again. An industry where the developers spend the majority of their time adding new, richer functionality to the delight of their customers and users, and don’t spend all of their time fire-fighting the imminent disasters to avoid those same customers and users having the really bad days.
Quality Code
A stitch in time
Some final pieces of advice:
- Code reviews are your friend, not your enemy. Comments made in code reviews are not an insult or a judgement of the developer’s abilities, they are trying to improve everybody’s code. A new feature may take twice as long to make its way into the system if it has to go through review and re-work iterations, but the end result will be more robust and more flexible to future changes.
- Automated unit testing (and integration testing) is your friend, not an annoying overhead. It’s true that they take investment to write and keep up to date, but any remotely non-trivial software system cannot live inside somebody's head. Even if it did, one day a different head is going to need to maintain it. Automated testing is how we capture what is in the head of the developer when they are writing it, and to ensure that we keep on checking that information going forwards whenever we make a change to the codebase.
So long, and may all your bridges be strong, stable and long lasting.