In 1992, Ward Cunningham spoke at an OOPSLA conference and used a metaphor to identify a serious problem that software teams were struggling to control.
“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unfactored implementation, object-oriented or otherwise.”
Ward’s metaphor has gained popularity, however, it’s initial definition has changed with each new interpretation. Ward continues to stress that technical debt is not a result of poorly written code, but rather the lack of future information that will lead the code to be less effective. In essence, technical debt is not intentional, or at least in the way is has been previously described. As development teams incur technical debt, their productivity ultimately decreases, creating interest for the technical debt. Ward emphasizes this when he states “A lot of bloggers at least have explained the debt metaphor and confused it, I think, with the idea that you could write code poorly to do a good job later and think that that was the primary source of debt. I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial.” When developers begin a project, they may think that the code they are writing is effective for the task at hand. However, throughout the course of the project, they may find that the architecture or structure is not as effective as once thought. These issues incur technical debt because the developer’s productivity is negatively impacted. It was not a careless error that caused the increment, but rather a lack of understanding.
It is essential to fully understand the concept of the metaphor and what point Ward was trying to prove when thinking about technical debt you might have collected. While the elimination of this debt is an ultimate goal, it is important to consider the focus of other goals your organization should have, the building of technical wealth.
When developers put time back into mending their ineffective code they are building technical wealth because they are essentially paying back technical debt. Legacy code that is difficult to improve is the key to building technical wealth . Going back and improving a code that isn’t written clearly and lacks insight into the developer’s intentions can be a difficult task. A way to avoid it in the future is to document your work and pay attention to detail. Adjusting the code down the line will then be a much easier task, thusly reducing the possibility of incurring technical debt. To build technical wealth, businesses must constantly be thinking of new ways in which they can strategize with the increment of technical wealth in mind. Steps taken now can save enormous amounts of time and productivity in the future.
The Human Error of Technical Debt
It is important to examine the human errors behind technical debt. A lack of communication between teams can create a confusing frustrating cycle of technical debt. Clear communication can ensure that the efforts and focuses for the team align, and build a future foundation of clear understanding. Increasing the effectiveness of communication between teams builds technical wealth for the future. Misaligned management and leadership can also be a cause for technical debt. Clear goals must be understood so that the best product decisions can be made to avoid the increment of technical debt in the future. Another human error that causing the building of technical debt is an ambitious push to market. Developing without testing to push it to market builds technical debt because of the corners the developers need to cut to get there. If a release date is in danger of being missed, it is the technical side that feels the negative effects.
Building Technical Wealth
Building technical wealth involves remodeling preexisting software to make it more effective in the long run. To begin building technical wealth, an organization must figure out how they will measure their success. They then must roadmap the issue and figure out how sensitive the technology will be to change, and what future implications this could have. An organization must also self reflect on their operational and organizational structure. Is there anything misaligned or slowing down that causes the building of technical debt? What does the focus on software maintainability look like on a quarterly roadmap? Or an annual one? These questions are critical to ask when putting in the effort to increase your technical wealth.
Agile Alliance, Introduction to the Technical Debt Concept, 2016
First Round, Forget Technical Debt–Here’s How to Build Technical Wealth