The term “technical debt” is one that tends to be thrown around a lot these days. Actually, the throwing around of this term is something that isn’t recent—it’s been going on for some time now. The problem with this term is one that is shared with various other industry terms … for instance: “agile”, “velocity” and “digital” to name a few. Simply stated: the problem is that these terms are heavily semantically overloaded. Not only that, but those most interested in marketing a product tend to be more interested in leveraging language to maximise revenue at the expense of keeping it pure (no suprises there, I suppose).
In an effort to correct the situation (to the extent to-which I have that sort of influence), I want to get into its origins, and correspondingly, the main meanings that it’s acquired.
Let’s go back in time.
1992: Ward Cunningham and Wycash
Ward Cunningham, famous in a few ways, not the least of-which being his connection with the first agile method, namely: XP, in around 1992 built a financial system (Wycash) using Smalltalk. In doing so, he coined a metaphor for a software-development specific phenomonen in order to better communicate it to non-technical stakeholders, that is: “technical debt”. In Ward's words:
… 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 …
So my take-away from the above is the potential misalignment between what a program does, and our mental model of the problem domain (“thinking about our financial objects” in Ward’s case).
Put another way: if you choose to take shortcuts in light of some non-technical constraint (money, time) which brings the way in-which a program works out of line with one’s current knowledge of the domain, the effect will be a built-in and persistent overhead (the “debt” component) required to compensate for the misalignment. This debt component is persistent in that it comes into play everytime a change is required to be made to the system; in that way, the comparison to interest repayments is appropriate.
There‘s a video of Ward explaining the concept floating around on the Internet—in it he makes a point of saying that it‘s important to make a distinction between poor programming and technical debt; they’re not the same. It’s also important to make sure that the code written is of a high quality in order to provide a means to pay the debt down at a later stage (or put another way: coding poorly will likely prevent effective debt repayment in the future).
2003: Martin Fowler
Over ten years later, enter Martin Fowler, and his Pascal-case-styled blog topic TechnicalDebt where he weigh’s in with a definition of his own. Martin uses the word design so as to carefully side-step the controversy surrounding the use of the term to refer to poor code. He does use another term which arguably is skating somewhat on thin ice, namely: “quick and dirty design” (specifically, the use of the word “dirty”). In this article, Martin gives credit to Ward for coining the term and goes on to extend the metaphor some with what Martin terms the Technical Debt Quadrant.
In the latter article Martin enters controversial territory by effectively suggesting that anything that affects ones ability to deliver value can fall into the technical debt bucket. This is in contrast to Ward’s original definition and assertion that poor code explicitly does not constitute debt (that is, the latter shouldn’t even enter the equation). Of course, Martin avoids the word “code”, electing to refer only to “design mess”. I think that this approach is more useful since, for all practical purposes, it’s naïve to think that poor code isn’t something that needs dealing with. Martin just classifies the source, in this case: “recklessly acquired debt”. The classification model is further enriched by giving it multiple axes:
- Is it something we know about, or something we're ignorant of (deliberate versus inadvertant);
- Is it something that’s taken on with a sense of responsibility (prudent) or lack thereof (reckless)?
2009: Uncle Bob Martin
Enter Robert Martin in predictable style, asserting the unacceptability of messy code, and in particular, eschewing the use of the term technical debt to refer to “a mess”. Bob is the poster boy for clean code (at least his definition of the same), and as much as in the past pockets of the community have enjoyed making him a target of derision, in truth I agree with his take, even if it’s a little heavy-handed at times. According to Bob,
… a mess is never rational, is always based on laziness and unprofessionalism …
Well yes, but also ignorance—if you don’t know what the good way is, then you’re not going to know that you’re making a mess, right? Martin’s technical debt quadrants are useful in expressing such a situation: inadvertent and deliberate. I suppose that being ignorant is the same as being unprofessional; the problem is that the yard-stick of a professional in this industry isn’t clear. Not only that … whatever it is, it's also in constant flux.
2019: Me
Metaphors are wonderful ways in-which to relate ideas, especially when dealing with difficult-to-express concepts. I’m a particular fan of metaphors because they make the esoteric accessible to the man in the street; something that would not be possible otherwise. That said, I am tired of this particular metaphor, in the same way that I’m tired of the other terms that have become sullied by indiscriminate semantic overloading. It really has become a way to refer to “poor practice” and an excuse for crappy delivery. Of course, I don’t think that it was ever meant to be that way, but as is the case with many other things in life, we don’t set out to behave badly; it just seems to happen along the way.
Comments !