Technical debt is incurred when software or system designers take short-cuts to ship a feature faster, increasing the overall complexity of the system. The goal is to optimize for the present rather than the future. In other words, it's the easier path which takes us to the end-goal faster but the resulting code (or design) is messy and complicated. It will require extra time in future to add new features or to fix bugs.
The most common reason why companies take on technical debt is to meet the time to market demands. "We must release this feature by February or our revenue will take a big hit. Just hack it for now and we'll fix it later."
There is another type of technical debt that is incurred inadvertently or unintentionally. Such as when a poor developer makes bad design choices or writes spaghetti code. This type is not the focus of this post. Instead we'll focus on tech debt that is taken on intentionally.
Technical debt is not always a bad thing and is a useful tool. When I worked at a startup, we intentionally took on tech debt because: a) what we were doing was very risky, b) we had a tight deadline to meet or the company would run out of money. No point in writing perfect code if it wasn't going to be ever released or used. Tech debt isn't the opposite of over-engineering. It is an intentional compromise to gain speed but making it harder to maintain or extend in the future.
Tech Debt is Demoralizing for Software Developers
The problem starts when companies forget to pay off the debt and let it accumulate and pile up. For good software developers, it is totally demoralizing to work on products that have high tech debt. This aspect isn't often talked about but it's effects are very real. Simple things like changing a title tag of a webpage page takes up a whole day because the logic was scattered in five different files. At the end of the day, it's not a great feeling that it took so much time for a small task. It's even more upsetting when they have to explain it to their managers, colleagues or the product team why it took so long. Troubleshooting a bug is not just difficult but also painful. Jeff Atwood called it a major disincentive to work on a project:
Beyond what Steve describes here, I'd also argue that accumulated technical debt becomes a major disincentive to work on a project. It's a collection of small but annoying things that you have to deal with every time you sit down to write code. But it's exactly these small annoyances, this sand grinding away in the gears of your workday, that eventually causes you to stop enjoying the project.
I'll add that it is not just a disincentive but actually soul-crushing if it is a large project with many other people working on it. Imagine finally finishing a feature only to find that it is not working on the QA or Stage environment because another developer from a different team changed something which somehow broke the feature you just completed. It festers and promotes intra-team conflicts and dissatisfaction.
Good software developers want to keep their skills up-to-date. Systems with high tech debt are very difficult to work with, much less keep up to date. As a result, developers are stuck with libraries and frameworks that are many years old. They fear they will break something so they avoid upgrading it altogether.
Cost of Tech Debt
The real cost of tech debt is ...
Read more at codeahoy.com
Top comments (1)
If you like this post, please take this short, anonymous survey on tech debt: surveymonkey.com/r/RGZCYW2 Results will be published in a week