Is it OK to have technical debt?
A few times now I’ve been asked to define technical debt. It can be an ugly term if your role is a project manager or scrum master. But, for me, as a more technically minded person I see this debt as a very normal thing that in an agile delivery team can be managed. However, before we can manage it, I’d like to use this blog post to define it (and get my own thoughts in order).
Let’s see what Dilbert thinks about it first. 🙂
With most delivery projects technical debt occurs very naturally and on a long enough timeline can’t be avoided. Feel free to argue this point in the comments below. All feedback is very welcome.
Those that say technical debt doesn’t exist for a given solution simply aren’t living in the real world or in exceptional circumstances have a green field project that is just starting out. In which case, zero multiplied by zero does in fact equal zero, because you haven’t done anything yet!
So… when you have done something…
Based on my experience as a solution lead and architect for various projects I would like to define technical debt in the following three ways.
1. Low Level Implementation Changes Encountered Following a Peer Review
Everybody codes differently, just like everybody has different handwriting.
With this mindset, technical debt could occur simply because developer 1 doesn’t like or agree with how developer 2 has written a block of code.
In these cases, we can often conclude that the code written is functional and does what is required for its given use case. But the senior developer doing the peer review would like it updated for various reasons. Maybe, simply to align the code with the standards set out by the solution architect. Or even just adding some extra code comments around a certain set of logic.
This type of technical debt will naturally grow over time with small amounts of changes needed/wanted in a solution. Especially if developers within a delivery team change.
To handle this, a small percentage of delivery capacity with each sprint could be allocated to addressing this type of technical. Time where the original developer can revisit the code and make the minor changes requested.
Nothing worrying about this technical debt. Perfectly normal and easy to deal with.
2. A Joint Design Decision Made to Implement a Tatical Solution Given Other Project Factors
Implementing a tactical solution to solve a problem vs a well thought out strategic solution often occurs due to time pressures or occasionally a skills gap within the team.
In this case, the architect, the technical lead, the product owner, maybe the project manager etc. agree that for the current circumstances the desired strategic solution can’t be implemented at this time. Therefore, a tactical delivery approach is taken.
To define this technical debt is to measure the effort difference between the tactical implementation vs the desired strategic approach.
This type of technical debt can be worrying, if taking a tactical approach happens too often. If time pressure was the reason a tactical approach was chosen, its highly likely the same time pressure will mean the technical debt is very addressed.
3. The Natural Evolution of Technology and Platform Standards
Advancements in technology can be viewed as both a burden and joy depending on your perspective. In either case, the outcome for an established platform will likely be technical debt.
- For a platform owner, a new resource standard/option could mean all instances of the given resource already deployed to production now require an update to the latest version or latest best practice. The effort of this update could be captured as technical debt.
- For an architect, a new resource option could mean an opportunity to innovate and improve the design of a given solution. For an established solution already meeting the original requirements, this re-design and re-implementation could be captured as technical debt.
Regardless of the scenario this type of technical debt isn’t worrying and typically just common practice in the I.T industry. Especially given the high velocity at which cloud providers release product updates.
One exception to this situation could be if the product update relates to a new security standard. If so, the update to meet the new standard should be given a high priority considering the impact of a potential security breach.
Conclusion
Simply put:
- Understand your technical debt.
- Understand where it happens using these definitions.
- Capture it realistically and honestly.
- Plan to address it.
- Don’t ignore it 😉
I hope you found my thoughts in this space useful.
Many thanks for reading.
Welcome to the Blog & Website of Paul Andrew 
For me it’s often a case of getting asked, “is it possible to do x”. I then fluff together some code, routine and data flows to say, “is this what you mean?” They then go yes it’s great don’t change anything because we’re using it live.
But it’s not parameterised has no error handling or documentation. “That’s OK just leave it as is, we’ve delivered what they want and move on. You can revisit those things when we get some quiet time” (yer right).
12 months later it needs a change and it take 5 times as long. Now that is technical debt for me.
LikeLike
Excellent read! Dealing w this now and it helps to have the scenario’s in my mind to recognize when they are about to or have already occurred.
possible typo: This type of technical debt can be worrying, if taking a tactical approach happens too often. If time pressure was the reason a tactical approach was chosen, its highly likely the same time pressure will mean the technical debt is VERY addressed. i’m thinking this should be EVERY instead.
LikeLike