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.
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.
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.
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.
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.
Some final pieces of advice:
So long, and may all your bridges be strong, stable and long lasting.