No analogies, no metaphors. This model is based off the excellent paper Defining, Measuring, and Managing Technical Debt by Ciera Jaspan and Collin Green. The findings come from the Engineering Productivity Research Team at Google based on five years of company-wide engineer surveys. This post is largely copied verbatim from the paper. Full credit to the authors.
Tech Debt is omnipresent and nebulous. We narrow it to only refer to the detrimental: Technical Debt or un-necessary complexity which hinders our work.
What is exactly is hindering us? Below are ten categorisations that emerged through engineering surveys at Google. I’ve amended these slightly.
- Migration is needed or in progress: This may be motivated by the need to scale, due to mandates, to reduce dependencies, or to avoid deprecated technology.
- Migration was poorly executed or abandoned: This may have resulted in maintaining two versions.
- Documentation: Information on how your project works is hard to find, missing or incomplete, or may include documentation on APIs or inherited code.
- Testing: Poor test quality or coverage, such as missing tests or poor test data, results in fragility, flaky tests, or lots of rollbacks.
- Code quality: Product architecture or code within a project is not well designed.
- Dead/abandoned code: Code that was replaced or superseded but not removed.
- Bit rot: The codebase has degraded or not kept up with changing standards over time. The code may be in maintenance mode, in need of refactoring or updates.
- Team lacks necessary expertise: This may be due to staffing gaps and turnover or inherited projects.
- Dependencies: Dependencies are unstable, rapidly changing, or trigger rollbacks.
- Release process: The rollout and monitoring of production needs to be updated, migrated, or maintained.
Breaking down the term Tech Debt into categories allows us to talk about the actual problems systems are facing. Through discussions and surveys we can pinpoint areas of high leverage to improve.
Ok, but we have a really old monolith with a lot of technical debt that the organisation has complained about for years ..
Defying some expectations, engineers do not select all of them! (Fewer than 0.01% of engineers select all of the options.) In fact, about three quarters of engineers select three or fewer categories. It’s worth noting that our survey does not ask engineers “Which forms of technical debt did you encounter?” but only “Which forms of technical debt have hindered your productivity?”
This simple model allows us to talk about our systems in a meaningful way. We can ask engineers which of the problems they face. The paper has a huge amount of detail and nuance. Read: Defining, Measuring, and Managing Technical Debt.
–
In a later podcast the authors were asked around objective measures (engineering metrics) that could be used to measure technical debt:
That was where that research started from was like, let’s see if we can have a logs based metric that agrees with the survey data that says this is roughly where tech debt is at in the code base. Unfortunately, that did not work as we would’ve hoped. I don’t think it’s impossible in the future, but I think the metrics that exist right now in both within Google and outside of Google, just aren’t really representing technical debt. Things like the number of to-dos does not accurately represent how people think about technical debt. Number of lint errors I know is another one I’ve heard people talk about is like, “Oh, if you’ve got a lot of lint errors is tech debt.” Well, not really. That doesn’t correspond with engineers perceptions either.
We did look at a wide variety of measures and we didn’t find anything useful. I don’t think that means that it’s impossible that there are measures out there. I think we need to keep exploring. That’s a place where there needs to be more research.
To learn where technical debt is, talk to engineers who work on the systems. To learn how technical debt is changing over time, run a survey with the categorisations above.