How do you organize your sock drawer? Are they neatly folded and set in rows? Are they balled up in pairs (potentially destroying the elastic!)? Or are they thrown in with reckless abandon, sometimes preventing the drawer from even closing properly?
This is a personal choice, but each represents a trade-off. Spending more time up front putting socks away versus spending more time struggling to find a matching pair and then turning on your dog and blaming him for eating everything you love. These kinds of trade-offs present themselves every day and we all perform an internal calculus weighing immediate vs differed cost. For some tasks this decision doesn’t matter but for others delaying can end up costing much more than it would have initially.
There isn’t an absolute right choice, and this is also true of technical debt in software. Technical debt is throwing a handful of socks in a draw in order to put them away faster.
Technical debt (also known as design debt or code debt) is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.
Wikipedia
This sock analogy starts falling apart at the seams (pun very much intended) since software can continually accumulate technical debt to the point where a project fails due to inability ship quickly or with good quality. While for socks, I have never met someone who quit wearing socks due to lack of sock organization of their sock drawer (if you are out there, let me know).
Don’t hide your sock drawer technical debt
There is no perfect solution to any problem. All solutions fall on a spectrum of technical debt even if we are not aware of it. We are always balancing constraints of cost, time, complexity and feedback. Sometimes the technical debt is obvious (putting a temporary workaround for a complex issue) and sometimes it’s more subtle (confusing code).
The first step to wrangling technical debt is awareness and acceptance. Foster a culture of transparency around technical debt; since technical debt is an inevitability there is no reason to hide it. Make explicit the technical debt is being accrued and discuss if the team accepts it.
On my team we talk about technical debt during our sprint planning, inside of pull requests and during roadmap discussions; routinely asking the following questions:
- What technical debt are we taking on with this change?
- How much does taking this debt save us now? (Since we are getting a change/feature quicker into customer hands).
- How much will carrying this debt hurt us over its lifetime? (Time/Money/Performance/User Experience)
- How much will it cost us to correct/fix later?
Asking these questions can have surprising outcomes. Sometimes we realize that the technical debt is not so bad, and we probably are ok never fixing it – since its negatives are minor, or the actual cost to fix properly won’t outweigh the savings.
Other times these questions prompt us to re-think the design/change we are making. Taking the technical debt can help us get a feature out faster but sometimes it clear that we will quickly have a bug farm (or to keep with the tortured analogy, only mismatched socks?!?).
Most of the time though it’s not a cut and dry decision. That is why having this discussion in the open with your team is critical. The team needs own the decision: Are we ok taking on this debt? And if so, what is our plan to fix it if we need to? Having the team agree to take it on helps everyone know of the trade-offs and be empowered to fix later. There have been times where I did not want to take the debt, but the team convinced me (and vice versa).
Depending on the results of the conversation, your team may:
- Not take the debt and rethink the design
- Take the debt and immediately file an issue for the next sprint to remedy
- Take the debt and file an issue on the backlog for future prioritization.
- Take the debt, record it, and wait since we anticipate not needing to fix it anytime soon.
Mending the debt
Making technical debt visible and soliciting group decisions is a simple step towards a healthier culture around it. A harder problem is how to reliably fix important debt and knowing which debt is important to fix.
As mentioned above, sometimes you know right away and can fund it immediately. Often though, you do not know the impact of a piece of debt until time passes. This may manifest as production bugs, high CPU or an incrementally more hostile codebase to develop in. Each of these can get severe enough to require action.
Monitoring and measuring are the answer. For debt that wasn’t obviously horrendous, how do you quantify the cost over time? There isn’t a one size fits all answer here but keeping a record of what the debt your team agreed to take helps. Periodically reviewing the debt and seeing how much of an impact it has had over the last N months can help guide some clear next steps.
Stitching it all together
Every decision is a trade-off and acknowledging them explicitly is a huge step towards awareness, analysis and correction when/if the decision turns out costly. Building this into your team process will lead to better outcomes and a healthier culture around debt.
Don’t be afraid to show your sock drawer for all to see. 🧦🧦