Overlooked Software Waste: Obsolete Code

Lean Software Management is an excellent approach for development teams who need to become more efficient and – more importantly – more mindful of their work system.  Even if you aren’t very familiar with Lean concepts, the underlying key principle is very simple: Eliminate Waste.  Waste, to use a simple definition is anything – anything – that is not adding value for customers.

Within this waste category are seven subcategories:

• Partially done work
• Extra processes
• Extra features
• Task switching
• Waiting
• Motion
• Defects

Partially done work, to quote Mary & Tom Poppendieck’s book, Lean Software Development: An Agile Toolkit:

Partially done software development has a tendency to become obsolete, and it gets in the way of other development that might need to be done.  [It] ties up resources in investments that have yet to yield results.

If the partially done work never makes it into production, that effort is effectively written off, which carries a significant financial impact.

But what about software that’s already obsolete?

Without citing chapter and verse about TQM and Quality Assurance processes, software carries an implicit total cost of ownership.  So often, we see a business or client who, on receipt of the product, smiles thankfully and never touches it again.  But software is like a house: it needs maintenance or it deteriorates.  The longer it is left to languish, the more holes begin appearing as time or technologies move on and extra features are gradually added over time, reducing its stability while increasing complexity.

So does obsolete code fall under the “partially done work” category?  In my view, close but it’s not quite a fit.  What about defects?

According to the aforementioned book:

The amount of waste caused by a defect is the product of the defect impact and the time it goes undetected.

This is probably a better fit for out-of-date code, but still doesn’t quite grasp at the insidious effect age has on software.  Even if no actual defects are encountered in a 6 or 7 year life span, the real implications aren’t felt until it’s time to upgrade the hardware or add that one last feature that requires a full rewrite.

I don’t believe it is any one person’s responsibility to ensure that software is regularly maintained and updated.  However as the team lead / development manager, you have a responsibility to clearly illustrate the costs and risks of aging code to the executive, client and any other decision makers.  Chances are this is the sort of topic that has been given approving nods and murmurs of agreement, followed by “we’ll definitely put that on our list of things to do… right after we finish the current backlog of work for this other project”.  Putting it off till tomorrow is a guaranteed way to ensure that it gets put off indefinitely.

Typically cost is another reason why investment is not made in existing applications or sites.  Too often the perception that “we just don’t have the budget for that right now” is an acceptable final word on software maintenance.  And that may well be true, but what is also left unappreciated is the rising cost to ultimately make the decision to upgrade.  The longer this is left, the harder to carry out it is.  Code ages, environments and operating systems come and go and complexity (or worse, convolutedness) increases as different developers come and go, adding their own style to the code base.  Saving a little money now neither does the developer, the client or the company any favours in the long term.

There are two (well, there are plenty but I’m picking on two) solutions to addressing obsolete software: push for (demand, even) a commitment from upper management to invest back into their software to ensure that the application doesn’t cost more to maintain (or even completely rewrite) in future.  Alternatively, just get on and start upgrading.  Explain that no more major enhancements can be facilitated until the code base is in a more stable and maintainable state.  One of these will probably meet more resistance than the other.  In my experience, it is often the former.  If a business has neglected an application to the point where it should almost be condemned, it also means they probably aren’t paying much attention to their software assets generally and are therefore either unwilling or unable to make good, cost and risk-based decisions.

Because ultimately, what is the alternative to fixing now or fixing later?  If your company is prepared to let its developers spend twice as much time (or more) adding new features or fixing bugs than they have to, perhaps it’s not the sort of company that has the sort of sustainable culture that allows a developer to thrive anyway.

Advertisement