Let's talk about Tech Debt

Following this excellent blog post by my colleague Raphaël Pinson, I keep asking myself, “But what does he call technical debt? What is his definition of technical debt?”.

This blog post is about the journey I embarked on to try and find some common ground definition of technical debt. This post will not give you the exact definition of what technical debt is, but rather concentrate on thoughts and reflections of some persons. The idea is to let you think about the concept, to start a discussion inside your organization and find a definition that fits your organisation or your team, in order to ease communication. Think about it like a “definition of done”¹, but for tech debt. Each team can have their own, but the definition must be clear to everyone.

How it started

Who invented the term “technical debt”? It seems to be Ward Cunningham, well-known for cosigning the “Agile Manifesto”.

Thoughts

Quentin Adam

Quentin is the CEO of a PaaS company called CleverCloud. If you understand French, I recommend watching one of the following conference talks: DevFest Toulouse 2018 or Voxxed Days Luxemburg 2016, Even if I don’t agree with him on everything, I cannot deny the fact that Quentin is a great speaker.

In his article, Technical Debt: The Myth at the Heart of the IT Labyrinth, Quentin develops the —controversial— idea that technical debt simply doesn’t exist. Software is an investment, and you reap the results of this investment. Developers need to stop flogging themselves about technical debt. He takes the example of deleting code. Most of the time, deleting code is a good decision, as it reduces features set, bugs, docs to write, etc… I really encourage you to read his article (available in French too). He also goes into detail about the fact that accountant vision of a line of code is not appropriate and that rewriting code is actually a good investment, but we are getting off-topic here.

Martin Fowler

Martin Fowler is a colleague of Ward Cunningham. He also signed the Agile Manifesto and writes many articles on his blog about technical debt, complexity, software engineering, and design.

In his article called “TechnicalDebt”, Martin defines the word “cruft”, which we could translate as “software erosion”. Software erosion is the decline of software quality over time. This cruft is quite inevitable. For him, the tech debt metaphor treats the cruft as a debt that needs to be paid. Over time, as the “cruft” grows, the effort required to make changes to the code base increases, which leads to a decline in velocity (which should, on the contrary, augment over time).

In his “TechDebtQuadrant” post, Martin demonstrates that there are multiple effects that cause “cruft”, or technical debt. It can be “rotten code” (badly written code), either intentionally or from not knowing fundamentals and tools. It can also be a shortcut, to meet deadlines.

In short, for him, every mistake leads to technical debt. You do not update to node 14? Tech debt. You did not write tests, and a bug got into production? Tech debt. Your design was wrong? Tech debt.

One problem remains though: as we cannot measure good design, we cannot measure technical debt.

Personal Thoughts

My thoughts about tech debt are, like Quentin Adam and Martin Fowler (or any other persons on the subject) controversial, subject to debate, and change over time.

Contrary to Quentin Adam, I found the concept of Technical Debt interesting because it let you put words on shortcuts you take in your design/code to meet certain goals (performance/deadline/whatever). I disagree with Martin Fowler though in a way that I have a much more narrow definition of tech debt. For me, external tools update (like libs, language version etc…) is not technical debt because it’s an externality, you cannot control it. But the shortcut the team does on purpose to the code base is “cruft” or tech debt. But if code review and tests are part of the dev (=meet the definition of done) then the team knows exactly what it is doing, and can track efficiently what needs to be reworked. Because taking a shortcut means writing the feature twice, I also agree with my colleague Raphaël which in his post advocates for standards. Even if you use old standard - let’s say, SOAP - you will still be able to deliver features at a fast pace because you don’t have to worry about the interface. Be proud of the value you are creating. Even if the tech you’re using is not “top noch” it is still value, and it is positive.

Other thoughts

Tech debt is a popular subject on the web. There are many other opinions out there, for example this one, from Steve McConnell blog’s, which goes way beyond the debt itself and goes into many organizational details. You may read articles on the subject but keep in mind that they often apply to specific context (big company, software editor, digital agency, etc…) which is maybe not your case.

Questions Asked Internally

I brought up this question of technical debt during a tech lunch at Camptocamp. Tech Lunch is exactly what you think it is:

Camptocamp pays the pizza
(or “Diot aux oignons dans son pain”)
You talk about something

Q: I don’t agree with your definition of tech debt

A: That was exactly the point! What bothers you about my definition? What is your definition? What is your context?

Q: Can I consider lack of documentation to be “tech debt”?

A: It can or even could! For some, lack of documentation is specific enough and fundamentally different from a technical point of view. In some teams people taking care of documentation are not the developers. From my point of view, an open-source developer, lack of documentation is more of an issue than tech debt because it is a huge obstacle to adoption of your software. Take Pyramid, for example. A python web framework, which is production ready. Pypi.org relies on it, but lack of documentation makes it hard to adopt and learn, while Flask, Django or FastAPI have impressive documentation. Tech debt is rather a blocker in contribution, not usage.

As you can see, it is rather a difficult question to answer and depends a lot on your context.

Q: Could the solution be to list all tasks related to tech debt in a specific board (or a specific place) to precisely know what tasks need to be accomplished to reduce the burden, while code base increases (call it entropy if you want)?

A: First what will you list in this list? Is upgrading dependencies considered tech debt? Is lack of tests considered tech debt? In my experience, this kind of “board” (call it whatever you want) is filled with a pile of “TODO”, “FIXME” tasks that are abandoned, and we never look at it because “the team needs to deliver a useful increment by the end of the sprint”. It requires a huge amount of self-discipline from the devs to maintain this list and, more importantly, find the courage to tackle those tasks!

Conclusion

As we pointed out in this article, it is quite hard, or even impossible, to put a final definition on what technical debt is. We encourage you to find the best definition in your team, the same way you would do for definition of done, for product definition, or for external lib selection: talk, exchange, confront ideas, ask questions. Technical debt is a great subject that lets you derive on a trillion other subjects like software quality, testing, code review, XP (extreme programming), Agile methods, velocity etc., just to name a few!