The Agile Maker's Dilemma: How Shabby is the Right Amount?

I am currently trying to invent a new kind of linear actuator to enable producing the "Gluss" robots: omni-triangulated robots built only out of members that change their length.

I am dedicated to applying Agile software methodology to my hardware making.

I just spent a precious three hours trying to build a spool of the proper size to hold a homemade magnetic coil. Was this the right thing to do? (I'm writing this essay as the epoxy dries.)

The fact is physical making brings to the fore decisions that are not as difficult in software development.  Agile methods have been described as "The Scientific Method applied to software development".  That is, the fundamental thing Agile methods try to do is to learn things as quickly as possible.  Generally, this is "learn what makes the customer happy."

Kent Beck created Test-Driven Development as a way to be Agile without actually being shabby.  That is, in TDD, you are always in the control, and you always have a set of a running tests that define the correctness and quality of your system.

In a way, TDD allows you to always be "correct", but to always be developing on the dimension of completeness.  You start with a correct but very, very incomplete system.  You always stay in control by staying in control of your tests, so you're software is almost never "wrong", but it is constantly getting more "complete".  In other words, quality is always improving, and all errors are in the form of things not yet done, not mistakes.

This is a very successful strategy, in part because software, whatever other problems it may have, is extremely repeatable.  The same program always does the same thing with the same input.  Software doesn't really wear out or rot, or stick, or rust, or get gummed up, or overheat.

But physically devices, especially my home-frabricated ones, do.  In TDD software, you have a smooth, monotone improvement, with small refactoring, but there are more variables and more compromises in physical making.

If I wind my coil too broadly as I did recently, I have no recourse but to rewind it.  If my piston doesn't fit properly in my cylinder, I may be able to adjust it, but I may have to make a new piston or a new cylinder.  Either a bad fit or a bad coil is likely to prevent my fundamental test from being successful: the actuator may not move.

I do not mean that you should not try to make physical things via a series of small tests. But I believe it is harder to do this when physically making than making software.

The worlds really needs a book entitled "Test Driven Development for Physical Makers: How to Choose When to Invest Where for Maximum Learning."