Spoiler Alert (about a year too late)!!!

So I'm 8 episodes into season one of BSG when the first glaring discontinuity raises it ugly head. Faced with the dilemma of finding a method for being able to detect Cylon infiltrators, the BSG crew serendipitously find a live copy of one of the two known Cylons/Human chimera in existence. Instead of using the Cylon to verify their screening procedure, they eject him out of an airlock. WTF!!! Using Boomer as the first beta candidate could easily have been attributed to a false positive, but comparing the outcome of her test against a live Cylon baseline would have given them the ability to identify both another Cylon in their midst and repudiate the unsubstantiated claim that Adama was a Cylon. What were the writers thinking?

In general, I like the whole re-imagining of the BSG universe with the Manchurian Candidate take on the Cylon infiltrators and the moral quandaries faced by the survivors, but this type of oversight does not bode well for the rest of the series. Hopefully it won't be quite as bad as the season finale I had the unfortunate privilege of watching out of context. When Boomer returns to the Viper without a helmet, the jig's up. Doh!

• Technical Debt
• Evaluate Your Technical Debt with Sonar

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.