No-Release Technical Debt
After 20 years in the software industry one grows accustomed to certain terms and eventually takes them for granted. You might already have suggested terms like “modularization” or “architecture” as primary examples. Everyone involved in the value chain of software delivery will probably have some idea of the definition of those terms, yet in my experience we seldom articulate those definitions. Another popular term that falls into this category is “technical debt”, which is being thrown around in many discussions by techies and non-techies alike. This post discusses technical debt from a perspective of your ability to release software to production.
The term “technical debt” was coined by Ward Cunningham as a metaphor while communicating with his manager at an assignment in finance domain, referring to financial analogy he called “the debt metaphor”, http://wiki.c2.com/?WardExplainsDebtMetaphor. Ward stated that “if we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were gonna continually stumble over that disagreement and that would slow us down which was like paying interest on a loan.”
In the aftermath the term technical debt quickly gained in popularity and naturally the widespread use of the term led to somewhat different interpretations of its meaning along the way. Here I will attempt to offer another approach that proved to be useful in the context of enterprise software in a complex domain.
Teams inevitably develop software or some kind of technical artifacts that address the needs and impact end-users. As thoroughly discussed elsewhere, e.g. check out the book on Impact Mapping https://www.impactmapping.org/book.html, every line of code is an assumption about the impact the code is meant to create. Naturally, assumptions need to be validated and the most efficient way to validate an assumption in software is to release to production as fast as possible. Released software fulfills its inherent purpose by providing feedback on the assumptions that the development team made when deciding to add a new feature. What happens with the software that, at any given time, has not been released?
The mass of software that has not been released is essentially just a pile of assumptions that have not been validated. The more unvalidated assumptions we make the greater the effort needed to align our understanding with the actual way of thinking by our users, just as Ward Cunningham initially envisioned. This grows in complexity if we keep adding new features without releasing to production, building new assumptions on that pile of previous assumptions, hence weakening the very foundation on which the software is being created. In the same way as an interest on a loan grows if you fail to pay a monthly loan term, the effort to validate all the piled assumptions, essentially pay back our debt, follows the same growth. Since the items that constitute the pile are technical artifacts the debt we create is technical debt.
In essence, if you have not released the software that you created then all that you have created is technical debt.
