A comment from Tom Cagley was the catalyst for my post “Design Communicates the Solution to a Problem”, and he’s done it again. I recently re-posted “Technical Debt – What it is and what to do about it” to the Iasa Global blog, and Tom was kind enough to tweet a link to it. In doing so, he added a little (friendly) barb: “Why not just do the work better?” My reply was “It’s certainly the best strategy, assuming you can“.
Obviously, we have a great deal of control over intentional coding shortcuts. It’s not absolute control; business considerations can intrude, despite our best advice to the contrary. There are a host of other factors that we have less control over: aging platforms, issues in dependencies, changing runtime circumstances (changes in load, usage patterns, etc.), and increased complexity due to organic growth are all factors that can change a “good” design into a “poor” one. As Tom has noted, some have extended the metaphor to refer to these as “Quality Debt, Design Debt, Configuration Management Debt, User Experience Debt, Architectural Debt”, etc., but in essence, they’re all technical deficits affecting user satisfaction.
Unlike coherent architectural design, these other forms of technical debt emerge quite easily. They can emerge singly or in concert. In many cases, they can emerge without your doing anything “wrong”.
Compromise is often a source of technical debt, both in terms of the traditional variety (code shortcuts) and in terms of those I listed above. While it’s easy to say “no compromises”, reality is far different. While I’m no fan of YAGNI, at least the knee-jerk kind, over-engineering is not the answer either. Not every application needs to be built for hundreds of thousands of concurrent users. This is compromise. Having insufficient documentation is a form of technical debt that can come back to haunt you if personnel changes result in loss of knowledge. How many have made a compromise in this respect? While it is a fundamental form of documentation, code is insufficient by itself.
A compromise that I’ve had to make twice in my career is the use of the shared database EAI pattern when an integration had to be in place and the target application did not have a better mechanism in place. While I am absolutely in agreement that this method is sub-standard, the business need was too great (i.e. revenue was at stake). The risk was identified and the product owner was able to make an informed decision with the understanding that the integration would be revised as soon as possible. Under the circumstances, both compromises were the right decision.
In my opinion, taking the widest possible view of technical debt is critical. Identification and management of all forms of technical debt is a key component of sustainable evolution of a product over its lifetime. Maintaining a focus on the product as a whole, rather than projects, provides a long-term focus should help make better compromises – those that are tailored to getting the optimal value out of the product. Having tunnel vision on just the code leaves too much room for surprises.
[Soap or oil press ruins in Panayouda, Lesvos Image by Fallacia83 via Wikimedia Commons.]
8 thoughts on “Technical Debt – Why not just do the work better?”
It emerges from the post that one cannot predict the future. I very much agree that this, in itself, is a good enough reason to attend to technical debt. As the myth goes, consulting the Oracle of Delfi may yield the right answer… but not for us. Many great software atchitectures could save a product from its doomsday if only they were avoided.
LikeLiked by 1 person
Technical Debt is the organizational, project, or engineering neglect of known good practice that can result in persistent public, user, customer, staff, reputation, or financial cost.
It is time that Technical Debt assessment and measurement be recognized in defense acquisitions and procurements and that its anticipation, avoidance, and elimination be incentivized. Accomplishing this is essential to the sustainability of the defense software industry.
While I agree with much of what was in your video, I don’t agree that “neglect of known good practice” accounts for all of it (though certainly that may cover a significant portion). At its core, I see technical debt as the gap between optimal and as-is. It represents a risk, sometimes greater, sometimes lesser. It absolutely should be recognized, recorded, and mitigated. Elimination of that which can attributed to neglect, ignorance, or even malpractice is a worthy goal. Recognition that sometimes a compromise is necessary to reach a business goal is, however, necessary too.
Some debt is useful when taken on advisedly and with an eye to retiring it. Other is like loaning your credit card to a group of drunken sailors. Trying to characterize all of it as either bad or good seems to simplistic – the only common denominator between the two is that both need to be managed and mitigated.
Great post! Technical debt can be useful, just as financial debt allows you to invest money before you make it. But unlike money, technical debt is typically largely invisible to the business. I agree with Don O’Neill that it should be measured. I propose a lightweight way of managing debt within a team here http://verraes.net/2013/07/managed-technical-debt/
I’m not aware of existing organisation-wide ways of managing technical debt.
Thanks! I definitely agree re: measuring and managing. I actually ran across your post last year and have it bookmarked.
Pingback: Technical Debt - Why not just do the work bette...
I agree that compromises are the main source of technical debt, but in my experience there is also a “gambling” aspect in which the developer takes the risk of assuming the technical debt:
Indeed…”compromise” is a bit of a euphemism. Some are informed decisions made after much consideration, some are Vegas style “let it roll” sprees.
In both cases, however, if the developer is the sole decision-maker, I have a bit of a problem with it. It’s a bit like a doctor making medical decisions on behalf of a patient – if it’s not an imminent life-threatening emergency with no hope of getting informed consent, it’s unethical.
LikeLiked by 1 person