Monday, March 24, 2008

Test Driven Design

I'm a huge fan of testing - but I'm an even bigger fan of test driven design.

Designing anything - documents, programs, methods with the assumption that someone's going to ask you about it and you need to reproduce on a basic level exactly what they're asking with no questions asked sounds easier than it is.

Let's say you're designing a system, and you say it has Symantec AntiVirus installed. Let's say you jot down that it's version 10. Is there anywhere in the program that will simply say "Version 10?" Chances are (and based on empirical data) that it'll say something like 10.1.5000. How do you justify to someone outside your own expertise that "10" is the same as "10.1.5000?" It sounds trivial - but imagine it in a bigger picture. Let's say you put down version "2" for something, and it turns out 2.1 is incredibly incompatible with your current setup. Even moreso, version "2" cant be tested anywhere, as the lowest release is "2.0.1." Make sense?

How can someone trust you if you don't design based on exactly what you can show them? The more transparent your design, the more your credibility rises.

0 comments: