What is technical debt and how does it hurt developer joy?
Introduction
This article introduces technical debt and establishes a working definition for it. Then, it presents the idea of developer joy and how a happier developer is more productive. Finally, it covers how technical debt harms developer joy by adding friction to the development process. Let’s start with an example to help frame the discussion.
Imagine asking a carpenter to frame a new room onto an existing home. The carpenter shows up to get started and finds that the home's foundation doesn’t extend under the proposed area for the new room. Digging in further, the carpenter finds that the home's existing walls have studs that are 48 inches apart, more than double the standards of their area. These existing deficiencies are technical debts that the carpenter must resolve as part of adding a new room to the home.
Imagine asking the carpenter to frame the new room with crooked nails and a measuring tape that measures in parsecs. Can the carpenter frame the home with such tools? Probably. Will they produce a high-quality frame? Maybe. Will the job take longer? Absolutely. Is the carpenter enjoying themself? No.
Imagine telling that carpenter to get written approval from someone not on the job site whenever they want to add another board to the frame. The carpenter can’t drive the job forward because they need constant approvals. The carpenter spends time working on the process rather than working on the frame.
The carpenter is frustrated by the technical debt, tools, and processes they have to work with. Developers have a similar relationship with their technical debt, tools, and development processes. The carpenter and the developer experience less joy because of the friction technical debt, bad tooling, and inefficient processes add to their work.
What is technical debt?
According to Wikipedia, technical debt can be defined as:
“The implied cost of future reworking that is required when choosing an easy but limited solution instead of a better approach that could take more time.”
According to Gartner, technical debt can be defined as:
“Teams “borrow” against quality by making sacrifices, taking shortcuts, or using workarounds to meet delivery deadlines.”
According to r/ProgrammerHumor, technical debt can be defined as:
“Move fast and don’t fix things.”
These definitions center around two key ideas: producing lower-quality work by taking shortcuts and saving time by taking shortcuts. Teams take shortcuts when implementing something to save time upfront but end up with a lower-quality solution. Repeatedly making this trade-off has a compounding effect that adds more friction to the development process. A development process with a lot of friction reduces developer joy and results in lower productivity.
What is developer joy?
Developers who enjoy their craft are more productive. Developers experience joy when they’re working on interesting problems using great tools as part of a low-friction development process. Developers experience less joy when they use tools that don’t work well or are inefficient. Developers experience less joy when their development process contains a lot of friction.
A developer experiencing joy likely works in an environment where they can ship high-quality code quickly, don’t spend a lot of time waiting, and can work independently and drive tasks to completion.
How does technical debt hurt developer joy?
Technical debt adds friction to the development process and makes it harder for developers to ship high-quality code quickly. As technical debt accumulates, a debt hierarchy forms as new work is built on top of old debt. This debt hierarchy adds additional friction to the development process as each new feature must be built around multiple levels of shortcuts, bugs, and hacks. This friction is the antithesis of developer joy.
Back to the carpenter example. The carpenter is told to use two nails in every board added to the frame of the new room instead of the usual four to save time. The carpenter spends half the standard time adding each board to the frame, completing the frame more quickly. However, the carpenter knows the nails need to be added eventually, or the frame will be rickety and unsafe. The two nails missing per board are technical debt.
The original plan for the new room includes installing a hot tub. Since the frame is rickety and unsafe, the structural engineer says the hot tub can’t be added unless the frame is reinforced somehow. The construction team modifies the original plan to include some bracing for the hot tub. Additional lumber is used to reinforce the joists underneath the floor where the hot tub will go to support the extra weight.
The original plan for the new room didn’t include time to reinforce the joists or money to buy the extra materials. The housing team built a workaround on top of a shortcut and ended up with a poorly framed house with additional parts. The extra work costs time and money and delays the completion of the house.
Software development follows a similar pattern. Teams save time implementing a feature by taking on technical debt. If the technical debt is resolved before things are built on top of it, the effort required to fix it will be low. The longer the technical debt is left unresolved, the more effort it will take to fix it as new features are built on top of it.
The contradictory nature of technical debt saving time in the short term while adding friction to the development process until it is resolved leads to cognitive dissonance for the developer. The developer knows that the shortcuts they’re taking will come back to bite them in the ass, and thus developer joy is negatively affected.
Conclusion
Development teams will continue to take on technical debt to hit deadlines. Paying off technical debt becomes increasingly difficult the longer it exists as new features are built on top of it. As technical debt compounds, it adds additional friction to the development process, and a high-friction development process negatively impacts developer joy. An unhappy developer is a less productive developer.
It is in a team's best interest to actively manage their technical debt and keep the amount of technical debt in the backlog under control lest it add so much friction to the development process that developers can't ship high-quality code quickly.
Additional Reading
Gartner on technical debt: https://www.gartner.com/en/information-technology/glossary/technical-debt
Wikipedia on technical debt: https://en.wikipedia.org/wiki/Technical_debt
Examples of technical debt: https://www.techtarget.com/searchitoperations/tip/6-technical-debt-examples-and-how-to-solve-them
The cost of technical debt: https://www.toptal.com/finance/part-time-cfos/technical-debt
Developer joy: https://svenpet.com/developerjoy/
Pillars of developer joy: https://www.atlassian.com/engineering/the-key-to-unlocking-developer-productivity
Was this helpful?
Thanks!
Warren Marusiak
2 comments