03 August 2023
In short, technical debt is the result of prioritizing rapid development or short-term solutions over long-term maintainability and code quality, leading to additional work and costs in the future. Although this sounds pretty bad at first, this is not always the case. In times where rapid development has to happen to validate product decisions or to move fast into a market this is totally acceptable and can be a valid strategic decision. However, engineering leadership needs to make sure that technical debt is addressed in the future. If not, this debt is paid on in the future by slower development times, buggy products, inefficiencies in the code and hard to understand and complex code leading to more delays in the future.
Technical debt needs to me managed in order to leverage it in the right way. This includes
It is all about balancing technical debt: Recognize that some level of technical debt is inevitable in software development, and focus on striking a balance between short-term needs and long-term sustainability.
At the end of April, Google has published a paper on how they handle technical debt. In the paper they are describing how they conducted an empirical approach by asking their engineering workforce some specific questions through their quarterly engineering survey. Among the questions they have asked were:
The initial goal of this was to identify as set of metrics within each engineering field they have. They hoped that with these metrics they could get proactive about managing technical debt by getting in front of it and being able to predict where technical debt would occur. They failed in doing this, but were able to identify 10 categories of technical debt:
In the paper they have ranked these categories from most occurrence (number 1) to least occurrence (number 10) and clearly stated that the ordering is probably unique for every organization. Where do you stand with your organization?
You can read the complete paper here
And idea that came to my mind how we could predict where we have technical debt would be to look at our automatic dependency resolving mechanisms (Depfu etc.) and measure how quickly these dependency upgrades can be integrated. In my opinion this could at least give us an indication of how well maintained our codebase is and how easy it is to validate that dependency upgrades cause no harm (good test coverage etc.). What do you think?