Life is too short to make all mistakes and then learn, so let’s learn from each other.
What is technical debt?
To put it simple, it is that “bad karma” of development teams.
Development teams constantly make decisions between building software right and building software fast. Even though building it right (quality) is always paramount, at times development teams compromise quality to gain speed (build fast). Rushing delivery of a feature or user story without ever going back to refactor the code to express your learnings leads to technical debt. In layman terms, it is like cutting corners to meet deadlines.
It’s a metaphor
Technical debt is a nice metaphor coined by Ward Cunningham. Technical debt occurs when a development team takes short cuts in delivering code that is not quite right for the programming task at hand. This debt decreases productivity. This loss of productivity is the interest of the Technical Debt.
This blog highlights five key pitfalls to avoid while dealing with technical debt. It is specifically written for development teams, IT delivery managers and product owners who intend to increase their on-time delivery, while still being flexible and at the same time deliver quality.
Pitfall #1: It’s not my problem
I’ve seen multiple Product Owners who think technical debt is too technical and they have nothing to do with it. That’s why most Product Owners assume it is something the development team needs to worry about. As a Product Owner, you want your team to deliver more features, but you should also allow them to invest time in improving the delivery capabilities. This means, as a Product Owner your interest is not only in product but also production capabilities. In layman terms, chopping trees vs sharpening your axe.
Focus on
- Getting familiar with the concept of technical debt. Understand some basic KPIs such as test coverage, cyclometric complexity, maintainability index etc. You don’t need to master them but you should know enough to know the impact of these KPIs.
- Do understand that systems with lot of technical debt will slow down development. So, this has a direct impact on TOC and ROI.
Pitfall #2: We need a separate sprint
Some teams postpone improvement work. There is an increasing cost of delay due to technical debt. Moreover, postponing improvement to a later point in time is a sign of waterfall mindset. I’ve seen teams plan for a refactoring sprint or stabilization sprint or any other name they want to put but all of them boil down to doing major changes without any business value.
Focus on
- Understanding that avoiding / reducing technical debt is not a choice for the team but it’s a responsibility they have every sprint.
- Preferring not to make any big bang refactoring to reduce technical debt. More often they will not result the desired outcome as they involve a higher risk of dealing with uncertainty.
Pitfall #3: It’s not too bad
There is a cost to not addressing technical debt. Early in its existence the cost of repaying technical debt is quite small, and it might very well take just a few seconds to work around it. If this is not done, there is a high chance that it might lead into a broken window effect. Dealing with small work-arounds throughout the code becomes part of a team’s status quo. There is a problem with this attitude toward technical debt. Technical debt doesn’t accumulate in a liner fashion, the longer an instance of technical debt exists in the code, the more code will around it and interact with it, thus making the debt more difficult to remove.
Focus on
- Pay Off Technical Debt Immediately. Ensure there are some automated quality gates (code analysis, build thresholds, automated NFR tests) and manual reviews in place to ensure you detect technical debt early.
- Ensure you have clearly defined quality thresholds, architecture guidelines and team agreements on design practices
Pitfall #4: Out of sight, out of mind
Technical debt is more like a black hole. It easily become invisible if you don’t keep an eye on it. That’s why it is important to use right tools and practices to have a clear visibility into technical debt. Tools such as SonarCude, Teamscale or SIG can help you get a better insight. Practices such as code reviews, design discussions etc. can help teams to keep technical debt in check.
Focus on
- Use information radiators in the team area to highlight key indicators
- Do talk about technical KPIs in sprint reviews and highlight how the trends have been in past sprint.
Pitfall #5: Not sharping the axe
One of the factor which might lead to technical debt is development team’s skills. For example, if they don’t know how to apply TDD or have a Continuous deliver pipeline implemented, there is a high chance that they might end up with technical debt. So, as development team focus on improving your skills.
Focus on
- Automate, automate, automate.
- Do have a technical excellence roadmap for your team so people can get some support on their technical growth path.
