Hey! Let’s all work together, please.
Technical Debt is a term which captures sloppy code, unmaintainable architecture, clumsy user experience, cluttered visual layout, bloated feature-sets, etc. My stance is that the term, Technical Debt, includes all the problems which occur when people defer professional discipline — regarding any/every technical practice such as product management, visual and UX design, or code.
I assert that the change we need to catalyze in the business community is larger than any one discipline and I am worried that I have seen an increase in blog articles in recent years about concepts like “Design Debt”, “UX Debt”, “Experience Debt” — these articles unfortunately are not helping and have served only to divide the community. They are divisive, not because we shouldn’t be discussing the discreet facets in which Technical Debt can manifest, but because authors often take a decidedly combative approach in their writing. Take these phrases for example:
- “Product Design Debt Versus Technical Debt” written by Andrew Chen
- “User Experience Debt: Technical debt is only half the battle” written by Clinton Christian
- “Design debt is more dangerous because…” written by James Engwall.
I agree with Andrew Chen that Product Design Debt is a problem — I just don’t like that he chose to impose a dichotomy where there is none. Why must he argue one “versus” another? Clinton Christian has implied that we’re in a “battle”. James Engwall has compared the “danger” of Design Debt relative to Technical Debt. These words are damaging, I argue, because they divert attention to symptoms and away from root causes.
The root cause of Technical Debt is that people forget this simple principle of the Agile Manifesto: “Continuous attention to technical excellence and good design enhances agility.”
The root solution to Technical Debt — all of its forms — is to help business leaders realize there is a difference between “incremental” development and “iterative” development so they may understand the ROI of refactoring. No technical expert should ever have to justify the business case for feature-pruning, refreshing a user interface, refactoring code, prioritizing defects. Every business leader should trust that their technical staff are disciplined and excellent.
Yes, please blog about UX Debt and Product Development Debt, etc. But please do so in a way that encourages cohesion and unity within the Product Development community.
Try our automated online Scrum coach: Scrum Insight
- free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.