Yes, it does matter.
I read a question recently about the importance of software maintainability:
“Does writing maintainable code really matter, when the company rarely adds new features, and they tend to scrap each version for an entirely new one every few years?”
Let’s examine a few rhetorical questions about the code this company develops.
No New Features?
Why does the company rarely add new features?
Is it because the code is not readable, maintainable, extensible, etc., and it’s too painful and costly to add a new feature? Or are there no requests from customers for new features because they’re grateful if they can just get the company to the fix bugs they report? Or are the customers worried that, if they request a new feature, something that works will break, so they just don’t ask?
Is the bug fix turnaround time long because the code was not written with maintenance in mind? Is the code brittle because it was not written with maintenance in mind?
It may not seem plausible, but it’s very easy to train customers to avoid asking for anything, because they know it will just open a can of worms, will take forever, and might throw the software they bought into a tailspin.
Why does the company tend to scrap each version for an entirely new one every few years?
Is it because the code is not readable, maintainable, extensible, etc., and it’s too painful and costly to fix bugs, add features, support new platforms, update the user interface, etc.? Is the code just too brittle to touch? Is it so brittle because it was not written with maintenance in mind?
The Cost of Unmaintainable Code
80% or more of the cost of a software product occurs in the maintenance phase. If you don’t pay attention to maintainability up front, you’re essentially sabotaging the maintenance phase, and effectively signing the code’s early death warrant.
Unmaintainable code tends to have a very very short life span, because it’s very costly to maintain, and it’s easier to justify the cost of a rewrite. Maintainable code tends to have a long life span, because it’s less costly to maintain, and it’s much more difficult to justify the cost of a rewrite.
Now, I don’t know this specific company or the type of product they’re developing. Perhaps there’s something special about the software that inherently has a very short useful life. But I’ve worked in and with organizations involved in a broad range of software development, and I can tell you that if anyone in the organization, whether it’s an individual contributor, a lead, a manager, a director, a VP, a CTO, or a CEO really thinks that developing maintainable code is not important, and allows unmaintainable code to be developed, they are being unprofessional, irresponsible, and wasteful. This is just poor stewardship. (I’ve helped to pull a few projects like this from the brink of repeating this software death spiral.)
If I were considering purchasing this company, or even buying a share of stock in it, and I heard this, I would walk away from the deal in a heartbeat. The company is just creating disposable “assets,” disposing of them, and then repeating the cycle. And I use the term “asset” loosely here, because unmaintainable code is much more of a liability than an asset, no matter how much they convince their customers to pay for it. The fact that the company just disposes of it and starts over implies that it’s a liability. No sane businessperson treats an actual asset that way.
Imagine how successful the company might be if they didn’t keep generating code that had to be thrown away.
You never really know how long your code might need to be used, no matter how large or small the project. I have written code that was expected to be used for a month to solve a specific problem, and then discovered later that it had been incorporated into a business process that ended up lasting for multiple decades. Had I not paid attention to maintainability up front, my code wouldn’t have survived. So, even if it looks like a short-term one-off, write your code as if it will have to be used and maintained forever.
Pay attention to maintainability, and it will pay you back.
You might also find these posts interesting:
- Writing Code that Humans Can Understand
- Why would my team ever need coding standards or guidelines?
- Think before you type – variable names and other entities