jump to navigation

Drive-by Specficiations – Part 1 November 16, 2007

Posted by ActiveEngine Sensei in .Net Development, ActiveEngine, Business Processes, C#, Problem Solving, TDD, Test Driven Development.
Tags: ,

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.


1. Bob Turek - November 18, 2007

Not being a software developer (but a big fan of agile methods), test driven development makes a lot of sense. I’m from the hard product community and testing at key stages of production, especially where you have a potential to drastically increase the value of the product, is essential and makes great sense. This appears to be the difference between a value based development model and a cost based one.

2. ActiveEngine Sensei - November 19, 2007

It is encouraging to hear that you are familiar with the Agile methodology. In many ways Agile is less familiar to people than PMO, and I have witnessed cases where senior management has torpedoed the concepts due to emotional reaction to vocabulary.

The benefits of delivery in short cycles and recalibrating can not be denied. After all, the software development cycle is expensive and the sooner the business unit begins to see deliverables the value of that system can be judged against the intial value proposed.

3. King-Size November Round-Up « ActiveEngine - November 29, 2007

[…] Dojo, with these topics of discussion: * Kick-off of the Test Driven Development series “Drive-by Specifications” which discuss the implications for the business partners, as well as how to approach […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: