The Agile Executive

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.