Sloppy technical debt

Tom Breur

15 January 2017

  

Technical debt is one of those intriguing metaphors in the Agile world that has intuitive appeal, it makes sense to the lay person, and also points to the often hidden dynamics of repayment and interest. That part I like. As of late, my thoughts on the liberal use of the word “technical debt” have been changing. Martin Fowler makes a useful distinction in his 4-quadrant model between deliberate and inadvertent accrual of technical debt, and reckless versus prudent choices. What I don’t like about the liberal use of the word “technical debt”, is that it tends to shield business decision making, by non-technical budget owners from the actual causes and consequences of so-called technical debt.

If I remember correctly, it might have been JB Rainsberger who pointed out to me that most of what gets referred to as “technical debt” in fact is, and should be labeled “sloppy coding” (or bad design). In Fowler’s model, both inadvertently (unconsciously) accrued, and “reckless” in that the longer term and downstream consequences are not properly considered. I genuinely resent using derogatory labels for colleagues’ behavior like “sloppy”, so it took me a while to get used to this term.

Nowadays using the word “sloppy coding” to call out supposed technical debt ‘works’ for me, for a few reasons. Almost every single day I can point to examples of sloppiness that I display myself, and where and how this is dysfunctional (not necessarily in coding, but that doesn’t matter much). I love using self-deprecating humor to refer to it, also to underscore my empathy with colleagues for accruing technical debt – specifically the examples that I’d prefer to call sloppy coding. Also, the liberal use of the word “sloppy” points to both the often unconscious, as well as dysfunctional nature of these (sometimes unconscious) choices.

If you can’t call out something for what it really is (calling it sloppy, rather than taking out a loan), then how can you be objective and rational about what the underlying dynamics really are? The cost-benefit trade-offs? If you don’t call a spade a spade, will you take responsibility for the costs and negative consequences? Or might you be tempted to sugar coat those consequences as seemingly harmless interest payments? Dunno. Since I genuinely believe quality is free, I’d rather do things right the first time around, and learn as much as I can from occasions where I have to do it again…