I've been ghosting YCombinator's Hacker News and one of the most interesting articles I recently read was by Martin Fowler on the idea of Technical Debt. Coined by Ward Cunningham, the idea is simple - taking a quick and dirty approach to a solution burdens a project with technical debt. This debt is the future effort required to refactor existing code into something more elegant, and ultimately more useful. While the concept explains why people may choose trade-offs in the name of expediency, what struck me most about the metaphor is how the role of testing in the development process could offset this technical debt as a form of "insurance". Tests preserve the original requirements without necessarily committing a developer to a specific implementation. So long as the implementation preserves the requirements, this technical debt can be managed.
One of the most direct measurements of software productivity is the ability to deliver on schedule. By accumulating technical debt, part of your development time is spent either servicing the costs of that debt (by having to code around the original hacks) or paying down the principle (by refactoring). This is the true cost of technical debt. When this debt begins to dwarf the principle value of an application, it is all to easy to default on this debt by slipping deadlines. While tests do nothing to reduce this debt, they prevent it from accumulating additional interest. Without tests, the situation quickly becomes untenable. Instead of Insurance, what you have is a Credit Default Swap. At this point, productivity is a synthetic derivative which has no bearing in reality. All productivity is lost in Complexity.
Put another way, is it possible to pay down technical debt without tests? I'm inclined to think not.
Since we're using economic metaphors, I'll use the prophetic words from the Oracle of Omaha which illuminate the cost associated with testing:
Price is what you pay, value is what you get.
The price incurred for having to implement and maintain tests far outweighs the value they provide for your application. The only certainty in development is that requirements will change as a program evolves. Tests are insurance against these "known unknowns".
As with all my articles, comments (not spam) are welcome.
