Maintainable vs Correct

Joe Eames recently put up a poll on Twitter asking whether developers thought the correctness of code was more important than maintainability. I voted for maintainability but many responders disagreed. Given the constraints of a 140 character tweet I thought I’d write a blog post to clarify my thinking…

Right up front I should say that code that isn’t maintainable doesn’t meet my yardstick for correct, which kind of renders the question moot, but I shall plough on regardless

The benefit of truly bad code that just doesn’t work

If code is truly bad and it just doesn’t work then at least it should have the merit of being obviously so. Which means that, whilst someone had to pay for it, nobody has to suffer the cost of putting it into production. Bad code is bad in itself, but it’s worse if you release it into the wild.

Of course you really should be asking yourself why it wasn’t picked up earlier. Anyhoo… This is not the code I’m talking about here.

It’s pretty clear that code that just plain doesn’t work has no value and there are some cases (medical diagnostics) where incorrect results cannot even be countenanced.

However, we’ve all published code that has bugs and I take incorrect in this context to mean code that works for some use cases but has bugs or performance shortcomings. This is the code I want to reflect on.

The awfulness of code that just works.

Any software project that breaks through the trivial barrier is expensive. A small development team might look something like this…

  • 2 Developers
  • 1/2 a UX designer
  • 1/2 a team lead
  • Some fraction of a business analyst
  • A tester
  • Some part of a product owner

All these people need desks, PCs and infrastructure. The team needs build servers, code repositories and agile tooling. The project will suck in people from the business and most likely external resources. To stand up a team like this for a year will surely cost at least 1/2 a million bucks, probably more. And that’s a small team.

You should expect your software to run for long enough to pay for itself, and given that it also has an on-going cost. How long will it take to repay this investment?

What’s the chance of requirements changing or new requirements popping up during your system’s lifetime? What are the chances new regulations forcing changes on you (all those legislators gotta do something)? If you don’t improve and update your system, what are the chances of your competitors leaving you behind?

I humbly submit that the answer to all these questions is “Pretty high“.

Code that just works, that works perfectly now but is not maintainable, is a huge liability waiting to bite you. Sure, you’ve possibly got some benefit or revenue from it for a while. But, by the time it bites you, you’ve got commitments to customers and reputational damage to worry about. By then you’re in so deep that the route out is painful and possibly fatal.

I have seen this scenario play out more than once and there’s always collateral damage. Mostly, but not always, it doesn’t kill the organization. It does lead to recriminations, loss of opportunity, loss of market share, sometimes loss of a whole market. It leads organisations to out-source and shutdown departments and it leads organisations that have out-sourced to sack suppliers. It almost always ends with loss of reputation. Code that just works is, truly, awful.

If it’s broke, I can fix it!

On the other hand how about code that’s got bugs (just about all code has bugs at some point in its life) but is maintainable?

Well the good news is it’s maintainable, so I can fix it quickly.

Better than that, it’s maintainable, so I can extend it quickly too. Now I can beat off my competitors with new features and constant improvement. There’s no reason to be afraid of new regulations and new requirements.

We’d all like to think we can always write code that has no bugs (we can’t). We’d all like to think the team got all the requirements up front and implemented them all perfectly (it didn’t). If this is what you do think, are you going to bet the company on it?

Maintainable code drives return on your investment, even if it has the odd bug. Unmaintainable code is the Devil’s spawn!

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.