Today I want to discuss tech debt management and old folklore. Let’s discover how to manage technical debt in agile teams with a unique analogy to the sin-eater. Learn strategies to reduce tech debt and improve software performance.
Tech(nical) Debt (noun): A debt of time and effort accrued during development cycles. This debt involves the time and effort needed to refactor code for better structure, performance, and maintainability.
Tech debt is a reality for most software engineering teams today. If your team doesn’t acknowledge the tech debt accrued, there are only two possible reasons: either your organization allows shifting deadlines to deal with unforeseen issues, or you and your organization are completely oblivious to the imperfection of being human.
The problem is that businesses inherently crave time and results. From a product owner or business user perspective, developer time is expensive, and they like to see tangible results for that time. The issue with technical debt is that its value is not easily quantifiable. When there is a bug, the time spent and the gain (less frustrated users, functioning systems, etc.) are easy to quantify, making it worth dev time. New features are also quantifiable in terms of gain versus dev time. With tech debt, however, we typically have a working system, so the business side doesn’t see a direct quantifiable gain for the dev time spent.
To get committed dev time to handle tech debt management, you need to frame it in terms that your business and product owners can understand. Communicate that while clearing tech debt won’t eliminate all bugs, it can prevent some bugs from being reported. Also, some tech debt must be cleared to ensure performance and scalability over time. Another critical reason is the potential for system outages, where response time and revenue loss can far exceed the dev time spent addressing tech debt.
The goal is not to clear all of your tech debt immediately. It’s unlikely that you can get buy-in to clear it all, especially in an organization with large or older repositories. Generally, the larger and older the repository, the higher the tech debt. Instead, it’s worthwhile to clear it incrementally and avoid incurring new debt as much as possible.
A strategy often favored by dev teams is to include tech debt in their definition of done or to address it while fixing bugs/writing new features. This strategy seems ineffective to me. In teams where we’ve tried this, we generally don’t see a decrease in tech debt because there aren’t bugs/features affecting those code segments, or we keep postponing it to the next bug/feature.
Enter the Sin-Eater
My suggestion is to create a role in your agile/scrum team akin to a sin-eater. The concept of a sin-eater is found in various folklores throughout history, most directly referenced in Welsh culture, originating around the seventeenth century. When a person died, they died with sin. In most traditions documented, as the corpse is laid out for viewing, a biscuit or small loaf of bread was placed on their breast. The bread would absorb the sins of the person over some short period of time. During the funeral, a person is hired to be the sin-eater. It is the job of the sin-eater to come to the home, and they’re provided with enough beer to help them consume the now sin-filled “funeral biscuit”. In doing so, it is believed that the sins of the recently deceased are washed away in the consumption by the sin-eater.
Sounds both delightful and creepy, right? Imagine a job posting on LinkedIn: “Our Lady of the Enduring Swamp Mortuary seeks an experienced sin-eater to consume funeral biscuits. Must have ten or more years of experience and a bachelor’s degree in sinful act conversion via carbohydrate delivery systems. Salary negotiable; beer quality dependent on mourners.”
If the profession sounds familiar, it has cropped up in a few pieces of modern media. The most recent and prominent I recall was season 5 of Fargo, where we saw the character Ole Munch. Sorry for any spoilers, but Ole Munch turned out to be incredibly old and owed that to his former profession as a sin-eater.
As peculiar as the profession sounds, it provides a useful analogy for modern software engineering. Think of tech debt as sins committed during the dev process to expedite speed, performance, or deadlines. Instead of committing murder or adultery, you’ve created an algorithm that runs in O(log n) time but consumes O(n³) space. This debt remains at the end of a feature/bug/story, like a lingering sin.
Consider gathering all these “sins” (tech debt) during a workshop or offsite, documenting them as stories in Jira, Trello, or whatever tool you use. Bargain with the business and product owners to move forward with new work but dedicate 5 story points per sprint or 20 per quarter to address tech debt management. Each sprint, the role of sin-eater is rotated or volunteered for, and a tech debt task is assigned to them.
While it may take time, as some projects have substantial tech debt, this strategy is better than doing nothing. Over time, as the role is passed around and the team collectively addresses the tech debt, it will decrease, leading to a happier team. Your team can decide whether to provide enough beer to tackle each sin. I’ve seen some tech debt that would likely lead to alcohol poisoning!