Technical-Debt-Driven Development (TDDD) is about to become the hottest craze. Here’s how it works.
The software development team doesn’t waste time thinking about solution elegance or future considerations. They simply focus on getting the code working. If it works, it ships.
Technical debt is leveraged as a means of accelerating the team’s efforts just as monetary debt is leveraged as a means of building wealth. Software development is faster as a result and the rewards occur sooner.
What’s the catch?
There’s one thing I have to mention. TDDD really only works well for small, short-lived, software systems. You see, you can’t grow monetary debt indefinitely. At some point, you can no longer keep up with the interest payments and the lenders will drag you into court.
You can’t grow technical debt indefinitely either. Eventually, the team will get bogged down managing the debt. They’ll have to spend large amounts of time reworking and refactoring source code leaving little time for adding new features to the software.
So is my TDDD concept useless? Is is dead on arrival? Not entirely.
The perfectionists among us lobby for the complete elimination of technical debt (TD). They suggest that TD must be avoided at any cost. If you don’t eliminate it now, you’ll have to eliminate it later and the job will only become more difficult over time.
Really? What if we eliminated all monetary debt from our economies? Many people would not be able to afford the purchase of a home or a vehicle. Many businesses would not be able to expand and grow. The resulting loss of monetary value would cause economies around the world to collapse.
Thankfully, the comparison of monetary debt to technical debt is not quite that direct. Software systems and their companies will not collapse without TD, but they may suffer unintended consequences.
Make good choices
Good agile teams know how to make good choices. They evaluate situations and respond appropriately. If the business is in a bind and needs quick turn-around on some stories, a good team will find a way, even if means taking on technical debt.
The alternative is to give code perfection priority over the delivery of business value. Fewer stories will be delivered in the short term and business opportunities may be missed. Perfection doesn’t help if if gets the business into trouble.
On a brighter note, monetary debt has to be paid off eventually but technical debt does not. Many software systems, or parts of them, will become outdated and no longer relevant long before TD has to be paid off.
TD belongs in the product backlog like any other work item. It can be prioritized and ordered along with stories and defects. Maybe it will get attention and maybe it won’t. Either way, the team will make informed decisions.
Software is never perfect and TD is not evil. Don’t listen to those who want you to adhere to their dogmas. They only make us less agile.