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...
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.
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.
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.
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:
Make technical debt a part of every conversation for all your projects
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