Agile Taguchi

When I think about it, I can see that Agile methods are aiming for a software equivalent of the Taguchi Method from product engineering. As I, Cringely says:

Taguchi's objective is robust design, which means building a product, system, or process that works well even in the presence of degrading influences. That means products that deliver value without breaking and services that are enduring while being as simple as possible. Taguchi first determines the control factors that go into designing a product, their interdependencies, then generates an orthogonal array specifying the number of experiments required to find the optimal solution.

If the last paragraph reads like Esperanto to you, maybe that explains why mainly eggheads have been attracted to Taguchi. The short version is that however they work, the Taguchi Methods can take a project with thousands, even millions of combinations of variables, and quickly reduce it to a couple dozen simple experiments that can be run simultaneously and will determine the cheapest way to achieve a goal. Instead of considering one variable at a time, Taguchi is able to test many variables at once, which is why the number of tests can be so small. It's a bloody miracle. Taguchi not only shows the right way to do something, it also tells you what the cost in dollars will be of doing it the wrong way.

Unfortunately, no one yet knows how to generate such an array for a software product. (Or, perhaps, it is just me that doesn't know how to do this.) You can make a feature array, but software is much more than a blob of features. But anyone able to apply the Taguchi Method to software would produce the greatest software ever—ever. And become richer than Bill Gates in the process.