Many times in the pursuit of delivering more and faster, organisations start accumulating Technical Debt. This can be a dangerous road that cripples their ability to deliver value in the long term.
What is Technical Debt
The term ‘Techincal Debt’ was created by Ward Cunnigham to represent engineering trade-offs made to quality for speed. Speed may be needed to meet some deadlines, customer expectations or unexpected events.
It generally ends up with extra effort to deliver functionalities that otherwise would have taken less time.
For example, consider I am working in a codebase, where a part of it is not properly commented or refactored. As a developer, assume, I have to put 1-day extra effort to understand the code, and maybe extra testing effort (let’s assume 1-day) also required to make sure my understanding was right. Now, this 2 days extra effort is the impact of Technical Debt caused by the poor quality of the code.
If we try to use the metaphor of financial debt that has a Principal and Interest, Technical Debt will be :
Principal = Effort to fix the low-quality code
Interest= Every time a teams’ effort increased because of the low-quality code.
Like in the above example 2 days extra effort is Interest. Imagine this is happening when multiple teams struggling with that code multiple number of times thoughout the life of the product.
Few examples of Technical Debt
- High code complexity
- Lack of integration tests
- Duplicated code or modules
- Lack of automated tests
When Technical Debt Is A Right Decision: at times, Technical Debt is a result of a conscious decision made to address some opportunities. For example:
- Creating a quick prototype and get some feedback
- Being first to the market to gain a competitive edge
- React to an unexpected event- ‘real’ emergencies
It is very much like companies taking financial debt to realise some opportunities. It allows them to react to the opportunity and create value. For a successful organisation value generated using debt generally is more than the principal and interest paid for the debt.
“Technical Debt is not necessarily a bad thing- as long as there is a real plan to pay it off”- From Masterting Professional Scrum by Stephanie Ockerman and Simon Reindl.
Side Effects of Technical Debt
Technical Debt Is Negative Value
Yes, you read it right, ‘Negative Value’. A negative value can be in terms of system downtimes, bad user interface impacting customer/user satisfaction, bad system performance, etc. These examples impact customer experience and create negative value.
Another great example of this can be unused features in the Product. These features consume time and money to be developed, tested, implemented, and documented.
Moreover, developers have to keep maintaining these features that also reduces their productivity. This is a negative value as this time could be invested in the innovation or shipping features faster in the long run.
Technical Debt Impacts Development Team’s Velocity
A few years back, I was working as a Scrum Master of a team. Our team was delivering some key product security features. However, many times development team members were finding some bad code created years ago. Nobody in the company could say with confidence that what could be the impact of such bad codes. Because of this uncertainty, the development team had to increase the testing effort to make sure nothing is broken and the product is still secure. Whenever we encountered such issues, our team’s velocity went down.
Technical Debt will impact the team’s velocity in the long run as the Development Team will be busier in fixing the Technical Debt than delivering the value.
It Will Get Harder And Harder To Work On New Features
Generally, the impact of Technical Debt is not linear, it is exponential. This means teams spend more time fixing the impact of technical debt or slow down to a crawling speed if the technical debt is not taken care of.
Teams will be creating more waste- rework or lower productivity. This will leave less time for them to work on new features. In other words, we can say is that a team’s ‘Time to Market’ decreases.
Technical Debt Impacts Transparency
Technical Debt is sometimes is not clearly visible or understood. It can cause a false impression about the quality and the progress of the Product Increment. It is like a hidden cost (rework or lower productivity) which impacts predictability.
For example, it will be hard for the Development Team to estimate the effort required to build features. The Product Owner uses the Development Team’s estimates to create Release Plans, Product Roadmaps and communicates with stakeholders. Because the estimates are flawed, this decreases transparency.
As we learned above, Technical Debt affects Development Team’s ability to deliver value in the long run. This impacts number of features a team can deliver or in other words there is less for stakeholders to inspect and validate value assumptions. This lack of ability to obtain feedback reduces transparency.
Ultimate transparency comes when your hypothesis and assumptions about the product and associated value are tested against the marketplace.
Lack of Motivation for Developers
Technical Debt slows down the progress for value delivery. This sometimes creates unnecessary pressure from the management. This is worse if management is obsessed with velocity.
It can be very frustrating for the developers as no-one likes being un-productive on a regular basis. Frustration keeps increasing when they have to give the same answer again and again.
Because technical debt increases the unpredictability, their estimates vary a lot with actuals and people start questioning developers’ productivity and skillset. In worst cases, it starts leading to blame game.
All of the above can result in demotivated employees.
Technical Debt Increases Total Cost of Ownership
Total Cost of Ownership represents direct costs such as costs related design, development, and testing during product development and also indirect costs such as supporting and maintaining the product over its lifetime. It is one of the important metrics for Product Owners to make their decisions.
Technical Debt impacts the Total Cost of Ownership of the product as the product becomes costlier to maintain over time. Teams get slowed down because of the poor quality. They spend more time fixing the production bugs. Operation costs increases as more incidents, complaints and calls get raised.
Product Owners must consider the impact of Technical Debt on the Total Cost of Ownership.
Technical Debt is a hidden cost that can impact value delivery, empiricism and also the team’s morale. Sooner you tackle this is better.
Next article we will discuss ‘How to Tackle Technical Debt’.
Till then stay agile and keep learning.