All Blog Posts
What is technical debt?
What is technical debt and how you manage it? Read our latest blog as we break down the in's and out's of technical debt...
3 min read
Development
Technical debt – or code debt – is the consequence of software development decisions that result in prioritising speed or release over the most well-designed code,”It is often the result of using quick fixes and patches rather than full-scale solutions.
Technical debt is a really interesting and tricky concept to pin down. Essentially it is a measurement or “gut feeling” for potential pain points in a piece of software. If something has loads of technical debt it is going to be really buggy, slow to work with, hard to change and as a direct result, your users are not going to be very happy with you.
If you have low technical debt you are very agile, you are able to react reasonably to changes, you don’t have a lot of bugs and most importantly, you don’t have your developers hating working in the codebase…or softly crying into their computers.
Similar to monetary debt, if technical debt is not repaid, it can accumulate “interest”, making it harder to implement changes. Changes required that are not completed are considered debt, and until paid, will accrue interest on top of interest, making the project a clunky build. Unaddressed technical debt increases software entropy and cost of further rework. Similarly to monetary debt, technical debt is not necessarily a bad thing, and sometimes is required to move projects forward.
I would even go out on a limb and say that is it nearly impossible to build a project with no technical debt whatsoever.
Types of technical debt
- Architecture Debt
- Build Debt
- Code Debt
- Defect Debt
- Design Debt
- Documentation Debt
- Infrastructure Debt
- People Debt
- Process Debt
- Requirement Debt
- Service Debt
- Test Automation Debt
- Test Debt
WordPress is a great example of technical debt out in the wild. In the early days their internal code quality was poor. So they racked up loads of technical debt because. The Founder of the platform saw a need for a product for self-publishing and just built it and shipped it quickly because there was an immediate demand for.
He took on a significant amount of technical debt in the codebase and that paid off for him!
It was well-received and users loved it. They couldn’t see that the backend was a flaming dumpster fire, but once he held the market share, was able to go back in and readdress all that debt. Had he spent years building it precisely by the book and on time, he would have missed the window for the demand.
Measuring it
There is no official way of measuring technical debt out there. To accurately measure it you need to have intimate knowledge of the codebase and have worked on it. Which makes it nigh on impossible for a program that exists that can measure what developers intimately know. In the same way a mechanic can’t just tell you what’s wrong with your car without really getting in there and sussing out the root of the problem, neither can a developer without working on the codebase for a bit.
You can’t quantify it easily. But that’s not to say that loads of people haven’t tried to create measurements, scales and programs that measure technical debt, and they are a good starting point BUT programmers tend to not solely trust these methods and go off their gut feeling.
Addressing it
With no deadline or budget, programmers could build *chefs kiss* perfect software, but that criteria just is not tenable for the majority of projects. Here are some handy dandy tips to stay on the up and up with technical debt:
- spreading awareness-the more developers and clients are aware of the effect of technical debt, the higher priority it can take
- following acceptable architectural coding practices
- maintaining a high percentage of code coverage
- using issue trackers to stay organised
- keep on top of your bugs
- work with trusted, knowledgeable developers of that codebase
- figure out pain points
- think up logical and reasonably simple solutions for how you can solve and implement them properly
- be given the time to do so
- think about future proofing
- strict system of addressing features and bugs
Make technical debt a part of every conversation for all your projects
Key takeaways
- not all technical debt is bad
- a small to medium amount of technical debt when you are launching a product is almost inevitable
- providing you manage it correctly, like a sharp knife, it’s useful, but it’s really easy to stab yourself in the foot
- you have to readdress it at some point or it will go wrong
- it’s tough to measure, but you can get one with some framework methodologies
- burying your head in the sand doesn’t work – you have to be transparent and address it
- don’t fight it, but do pay it off!
In an ideal world, technical debt wouldn’t exist. But just like real debt it is a necessary evil in some projects. At times, it’s going to be unavoidable to take on technical debt (and it’s definitely not always a bad thing to take on), but it’s just important that you go back and pay off that debt to ensure the ongoing health of your product.
If technical debt starts to get out of control, you’re the one that’s eventually going to feel that pain. If you can make addressing technical debt an organisational value across your product and development teams, you should be able to better ensure the long-term agility and bullet proof product.
Published on February 28, 2022, last updated on March 3, 2022
