)
)
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. ProductPlan
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 Tom Yeadon, Server Team Lead
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 28 February 2022, last updated on 3 March 2022