Okay Agilists, it’s time for the final judgment on good enough code. You think you can just skim by with your iterative out-the-door approach to delivering program architecture? Well, maybe you can. As Jason Bloomberg writes in a DevX.com blog, there are really two kinds of technical debt. One is fine, the other unacceptable.
Before Mother Comes Home
Bloomberg puts it this way: As a software developer, it’s sometimes necessary to set aside good design principles in pursuit of deadlines or cost savings. In the short term, this usually works out fine, but eventually someone must clean up the poor quality of programming, since technical debt accrues interest over time in the form of increasingly faulty code:
Over time the issues that result from code shortcuts start to compound, just as interest does – and the refactoring effort required to address those issues is always more than it would have taken to create the code “right” in the first place. But I put “right” in quotes because the notion that you can fully and completely gather and understand the requirements for a software project before you begin coding, and thus code it “right” the first time is the fallacy of the waterfall approach that Agile was invented to solve.
Thing 1 and Thing 2
The basic premise of Bloom’s take on technical debt is that there are actually two kinds:
Thing 1 – Sloppy Code
Thing 2 – Technical Short Cuts
The first kind of debt is the unacceptable version. Poorly written code is faux-debt because it doesn’t really make sense to fix it later. That would be too costly. When developers speak of technical debt, what they are really referring to (should be referring to) are intentionally designed technical short cuts. Short cuts and simplifications are planned and can be mended in a cost-effective manner. They are made to be fixed with time and cost constraints in full consideration. One way to plan for technical debt according to Bloomberg is through a meta-architecture.
You can learn more about Bloomberg’s meta-architecture at: http://www.devx.com/blog/agile/architecture-technical-debt-the-curse-of-agile.html