Imagine you’re taking a trip to catch up with one of your best friends. You also need to get a few things from the shop; let’s say, a couple of pints of milk. You have a choice. You could head directly to your friend’s house and be on time, and do the shopping later. Or alternatively, you could change your route, visit the shop, and arrive at your friend’s place a little bit later than agreed. This really simple dilemma encapsulates what technical debt is all about.
When it comes to software, software engineers may prioritise some development activities over others due to the need to either ship a product, or to get a service working. The impact of prioritisation may have implications for software engineers who have to take over the work at a later date.
As suggested earlier, software can quality attributes: it can be efficient, it can be secure, or it can be maintainable. In some cases, a software engineer might prioritise getting something working over its maintainability or comprehensibility. This means that the software that is created might be more ‘brittle’, or harder to change later on. The ‘debt’ bit of technical debt means it will be harder to migrate the software from one operating environment to another in the future. You might avoid ‘paying’ or investing time now to get something working earlier, but you may well need to ‘pay down’ the technical debt in the future when you need to migrate your software to a new environment.
On Managing Technical Debt
In SE Radio 481: Ipek Ozkaya on Managing Technical Debt, Ozkaya is asked a simple question: why should we care about technical debt? The answer is also quite simple: it gives us a term to help us to think about trade-offs. For example, “we’re referring to the shortcuts that software development teams make. … with the knowledge they will have to change it; rework it”. Technical debt is a term that is firmly related to the topic of software maintenance.
Another question is: why does it need to be managed (5:10)? A reflection is that “every system has technical debt. … If you don’t manage it, it accumulates”. When the consequences of design decisions begin to be observed or become apparent, then it becomes technical debt, which needs to be understood, and the consequences need to be managed. In other words, carrying out software maintenance will mean ‘doing what should have been done earlier’ or ‘adapting the software so it more effectively solves the problems that it is intended to solve’. My understanding is that debt can also emerge, since the social and organisational contexts in which software exists naturally shift and change.
Interestingly, Ozkaya outlines nine principles of technical debt. The first one is: ‘Technical debt reifies an abstract concept’. This principle speaks to the whole concept. Reification is the ‘making physical’ an abstract concept. Ultimately, it is a tool that helps us to understand the work that needs to be carried out. A note I made during the podcast was that there is a ‘difference between symptoms and defects’. Expressed in another way, your software might work okay, but it might not work as effectively or as efficiently (or be as maintainable) was yo would like, due to technical debt.
It is worth listening to Ozkaya’s summary of the principles, which are also described in Kruchten et al. (2019). Out of all the principles, principle 5, architecture technical debt has the highest cost of ownership, strikes me as being very significant. This relates to the subject of architectural choices and architectural design.
Krutchen et al. suggest that “technical debt assessment and management are not one-time activities. They are strategic software management approaches that you should incorporate as ongoing activities” (2019). I see technical debt as a useful conceptual tool that can help engineers to make decisions about practical actions about what work needs to be done, and communicate to other about that work, and why it is important.
Reflections
I was introduced to the concept of technical debt a few years ago, and the concept instinctively made a lot of sense. Thinking back to my time as a software engineer I often were face with dilemmas and trade-offs. Did I spend time ‘right now’ to change how I gathered real-time data from a hardware device, or do I live with it and just ship the product?
The Kruchten text introduces the notion of ‘bankruptcy’. External events can cause business bankruptcy. In the case of software, this was facilitated by a software vendor ending support for a whole product line, and the need to rewrite a software product using different languages and tools.
When looking through software engineering radio I noticed an earlier podcast, SE Radio 224: Sven Johann and Eberhard Wolff on Technical Debt covers the same topic. Interestingly, they reference a blog post by Fowler, Technical Debt Quadrant, Fowler suggests a simple tool that can be used to think about technical debt, based on four quadrants. Decision about technical debt should be ‘prudent and deliberate’.
Returning to the opening dilemma: do I go straight to my friend’s house, or do I go get some milk on the way and end up being late? It depends on who the friend is and why I am meeting them. I depends on the consequences. If I’m going round there for a cup of tea, I’ll probably get the milk.
Resources
Fowler, M. (2009) Technical Debt Quadrant. Available at: https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
Kruchten, P., Nord, R. and Ozkaya, I. (2019) Managing Technical Debt: Reducing Friction in Software Development. 1st edition. Addison-Wesley Professional. Available at: https://library-search.open.ac.uk/permalink/44OPN_INST/la9sg5/alma9952700169402316