ActiveEngine

Drive-by Specficiations – Part 1 November 16, 2007

Here’s a concept that’s new for the business community. A team will produce a product that meets your goals, but must write programs to test your new program.

Why? That must be more inefficient since you’re doing twice the amount of work. Why can’t you just do what we listed on the specification we gave you? What about all that talk about necessary and sufficient?

Test Driven Development is often mis-understood, and that’s unfortunate as the business community can greatly benefit from this approach to developing software solutions. Yes, there is additional programming required, but think of this effort as validation of a contract, and that contract is the set of criteria that you have given the developers. By following the proscribed approach, the developer will have thought through each facet of the code that leads to the fulfillment of the specification. No other code is written other than that which will fulfill passing a test. This greatly focuses on what is necessary and sufficient as nothing should be concentrated beyond the boundaries of the set of tests. The test are like that piece of paper with stick figures Al and Wu used to communicate to each other.

It must be noted that an advantage here is that when changes are made later on, as they always will be, the tests can be repeated again and it can be quickly determined if the alterations have broken other facets of the program. Luckily the execution of these tests can be automated, for as you can imagine you quickly end up with lots of tests.

Only after all tests are passing then the developer can perform enhancements as the tests will gage whether or not the program still functions as specified. Most programmers forget this part, as the artisan within can often subdue pragmatism, and some, but not all developers, will continue to will continue to develop code that will be used for the future, yet will not have hit the targets of the original specification. The tests will help re-enforce the boundaries. Who? Wu? No who, Wu! No Wu? Right here on the paper you idiot!! Yes, you should really yell like that at the programmers!

Heres a set of criteria, the basis of our program:

Process an increase in commission of sales for each customer:

• For customers that have been with our product line UltraSlim for 5 years or less, increase by 4%. All other UltraSlim customers increase by 6%.
• For customers that have been with our product line UltraSmart for 3 years or less, increase by 2.5%. All other UltrSmart customers increase by 3.5%
• Do not apply a commission for those customers who have been with either product line since 3rd quarter of the current sales year (calendar year based).

Seems like a lot? Consider this, if this is the criteria and the means for communicating you quickly begin moving in concert and hit those sweet spots of productivity. You’ll find that you’ll discover contradictory criteria that you may have supplied, and you’ll both spot errors more quickly. That flow productivity and ideas will become your ActiveEngine for great software creation.

The next part in the series will discuss how these tests are validated, and will be technical in nature but of benefit to the business community, as when done properly they will communicate what the developers are doing with the code.