Thursday, July 7, 2016

The tester and technical debt

Technical debt is one of my favorite topics, as I feel that the fact that I as a tester have heavily addressed it in support for my team for the last four years is the reason why we're able to release on a daily basis even without test automation.  So whenever I get a chance to eavesdrop and start to think about it, I do.

I was eavesdropping on a conversation by Llewellyn Falco yesterday, that lead me to tweet an insight.
Since we call technical debt with that term, there's a lot of talk around that keeps thinking of the mechanism of how it's born as if it was a deliberate choice, like walking into a bank and taking debt. But that is really not my experience. Technical debt is much more like the infinite amount of small decisions you do on how you eat to either gain weight or not. It's not really deliberate, it's more of an accident. And just like weight, when you gain some technical debt it can be really easy, but the work on losing it will be significant and continuous, and needs to focus on changing the habits for sustainable results. With every relapse, it will get more difficult to find the willpower to stay on it. There's a difference on something being a choice or a consequence of your choices. You can influence  both, but the latter is harder.

As a tester in my team, I've been a beacon to remind the team to stay fit on technical debt, because when we don't, I see the consequences first hand on the surprise bugs that messy code gives us. I see the slowness of adding something seemingly simple. And unlike a lot of managers, I won't be fooled with the "coding is magic and magic just takes time without explanations", because I'm all in with the team.

I speak to the managers about letting the team address technical debt as they recognize it. Recognition comes through learning more about what is and is not good. I provide information that enables making the room for this through continuous positive feedback and evidence that I see while testing that we're on the right route. And I act as someone who keeps reminding that none of us is ever alone with this in a team.


  1. I love the analogy of technical debt as putting on weight. That is exactly how I see it happen in my context as well. Many little excuses and "I'm too busy to do this (or eat) right" add up to big, hard to solve problems in the future.

  2. While I wholeheartedly agree with the content, I do not agree with the semantics.

    Technical Debt is being misused everywhere, but originally (according to W.Cunningham who coined the term first), Technical Debt IS a deliberate choice, knowingly taking shortcuts to meet a deadline for example (hence the "Debt" metaphor, short term — and sometimes beneficial — results, but interests to pay in the long term).

    The "putting on weight' metaphor is more for bad practices or a lack of focus on code quality.

    Basically, the result is bad code / software quality issues, the causes can be either technical debt (conscious) or bad habits / lack of focus on quality (unconscious)

    Or like Uncle Bob says :

    "A mess is not a technical debt. A mess is just a mess. Technical debt decisions are made based on real project constraints. They are risky, but they can be beneficial. The decision to make a mess is never rational, is always based on laziness and unprofessionalism, and has no chance of paying of in the future. A mess is always a loss."

    1. I'm aware of the definitions. However, the world does not seem to follow definitions. Debt is something you owe is more of a common understanding.

      And even with "real project constraints" - the fact that code when extended feature by feature ends up sloppy if we don't actively keep cleaning it up as our understanding grows is a way of ending up with a mess.

      Learning creeps in, and makes us realize what we thought was good was not. And when we learn, we do better as we're better. It does not stop us from being professional in the first place. Professional != Perfect to begin with.