The “Simple Case of A500” occurred 10 years ago. I’m currently coding the “Son of A500“. Completely different companies, completely different products, a decade apart. I’m the only common factor. And even I’m different.

The Simple Case of A500 started with a request to automate a recipe generating function. For an example, the customer provided a copy of one recipe, you guessed it, A500. Bravely we marched off, returning a month later with the ability to automatically generate the recipe for A500!

Making a long story short, it turned out that A500 represented the simpler recipes in the class, and for extra enjoyment, the example they provided was the simplest of the simple. It took another 2 months (which means the project took 3 times longer than planned) to finally get the client what they REALLY wanted.

The take home lesson we learned, “Don’t accept a single example for requirements that cover a class.” We even referred to ensuing similar requests (from them and other clients) as “Oh yeah, it’s the simple case of A500.”

Ten years later, I’m still getting requests for “Don, do this, and here’s an example.” The current case started as “We need to be able to detect faulty thermocouples.” and a dataset that showed one of three thermocouples not working correctly.

Being older and wiser, I’m now working with the clients helping them understand that, “Yes, we can handle the request, but with a single example, I can’t ensure that we’ll handle a significant portion of the class, much less all the possible permutations that could arise.” It usually takes a lot more words, but so far I’ve been successful helping the clients understand the need for better requirements definition and examples.

Got an example of “The simple case of A500”? Send me an email. don at donaldegray.com