Elbow Room for Handling Technical Debt
It has become something of a pattern recently. Somebody contacts me about software that has become extremely difficult to maintain. Irrespective of the domain in which the software is applied, the situation is usually characterized by an overwhelming amount of technical debt accompanied by an unaccptably high error feedback ratio. Between those “twins”, both customer support and development are thrashing to the extent that development of new functionality has pretty much ceased. “Just” maintaining the software consumes 90-100% of the cycles of the development teams (and >100% of the cycles of the customer support team).
I do not really mind being considered kind of “Software 911” service. What I find fustraing, however, is that I (and other consultants) typically get called too late. The technical debt when we get called is so overwhelming that it is extremely difficult to generate the cycles required for refactoring the code and establishing solid software engineering practices. The refactoring “medicine” can’t be taken because customer crises leave no time for learning how to refactor nor for carrying out refactoring in a thoughtful manner. Folks trying to refactor the code get interrupted so often to deal with crises that any attempt to establish flow gets in trouble. The elbow room required for systemic refactoring work simply does not exist anymore.
I am not quite certain where the fine line between “Software 911” and “Pathology 911” lies. My hunch is that once >50% of development resources are assigned to maintaining the software on an on-going basis, it is time to get into refactoring big time. If you don’t, sooner or later you are likely to find you can’t afford the software you developed.
The Agile Executive 
With some places I’ve had to introduce the concept of software bankruptcy. At some point, it makes little financial sense to keep investing in a code base with excess debt. It can be radically cheaper to start fresh.
Unfortunately, no matter how clear the numbers, many executives are unwilling to admit that they’ve gotten into so much technical debt that their project is worth less than nothing. Although they’re willing to accept that a collision-damaged car is totaled and should be scrapped, they just can’t (or won’t) understand the same thing about a software system.
William Pietri
October 7, 2009 at 9:37 pm
1. Indeed, software bankruptcy is a powerful concept. Everyone gets in (at least intuitively) and it leaves no room to hide.
2. I am actually amidst compiling a post on the costs and implications of starting afresh. Attractive that it might look, starting afresh poses numerous problems IMHO. I will publish this post (on starting afresh) next week.
Israel
Israel Gat
October 8, 2009 at 5:51 am
[…] simply continue a struggle that becomes more and more difficult over time. As indicated in the post Elbow Room for Handling Technical Debt, the second option is quite difficult to carry out if it is exercised at a late point in the […]
Technical Debt: Refactoring vis-a-vis Starting Afresh « The Agile Executive
November 10, 2009 at 4:29 pm
[…] Affordability: The question to ask is whether you can afford not to improve your software. Tools are readily available to quantify your company’s technical debt. Monetize the technical debt and include it as a liability line item in a pro forma balance sheet. Doing so is likely to shift the discussion from affordability to how to create elbow room for handling the technical debt. […]
It Won’t Work Here « The Agile Executive
December 7, 2009 at 5:46 am
[…] reduce your technical debt instead of trying total rewrite. Chances are you will struggle to find Elbow Room for Handling Technical Debt. My hunch is that once >50% of development resources are assigned to maintaining the software […]
Is There Something Inherently un-Agile About ERP Software? « The Agile Executive
December 30, 2009 at 5:47 am