Technical Debt and Accountability
I am wrapping up my second in a series for Clean Coders on Technical Debt. In the first episode, I explain the Technical Debt metaphor, how it originated, how it changed over time, and how it now is commonly understood in a way that is the opposite of what it originally meant. I talk a bit about the limitations of metaphors and how debt in particular has not served us well as a metaphor over time. So when a link to an article on the "Limits of the Technical Debt Analogy" hit my inbox this morning, I was quick to follow the link and see what the author had to say.
Unfortunately, this article is not at all about the limitations of the metaphor. The article is about how people other than those who write the software are responsible for the quality of the software. This article is bunk.
The author explains that technical debt (Reckless Technical Debt) is the result of pressure from a project manager pushing the team to deliver quickly in the early stages of a project. This seems to be a given in the author's world. The mention of a project manager driving the project is sufficient evidence that debt has incurred.
According to the author, once delivered, the project moves from a project manager to a product owner. The product owner is primarily interested in self promotion and fast tracking their career, so they continue to incur debt to lower maintenance costs and make themselves look good.
From projects that go live before they have a product owner to the fact that project managers "ru(i)n" projects and product owners don't care about the product as much as their own skyrocketing career, this article is full of givens that don't match my reality.
But none of these things are my core issue with the article.
My core issue is the failure to acknowledge any role or accountability developers have in the creation of technical debt (cruft). Per the article, the project manager and product owner create the technical debt. This is like saying the restaurant manager burns the food or the general contractor installs faulty wiring or the hospital administration botches surgeries. While there is certainly some involvement in terms of expressing expectations and creating a particular environment, none of the people in these roles commit the actual act. The chef burns the food, the electrician installs the faulty wiring, the surgical team botches the surgery, and the developers write the crufty code. Abdicating one's professional responsibility doesn't make one any less accountable.
In this article, the developer is the hero, who defies social stereotype, is creative and communicative, and in a stroke of genius comes up with the Technical Debt metaphor to explain it to people who are clueless about code. But, alas, greed, self interest, and silos cause Project Managers and Product Owners to continue to create technical debt even after the developers so eloquently explained it. If only the hero did the right thing instead of crafting a metaphor to explain how somebody else is forcing them to do the wrong thing.
The inimitable Ward Cunningham first wrote about the Technical Debt metaphor in 1992. While this was perhaps a stroke of genius, he was not speaking about crufty code and he was certainly not laying blame at the feet of others.
Here are more of my articles on Technical Debt.