2013-11-09

Iterative development and physical objects.

Decades ago, programming a computer consisted of punching small holes in paper cards and feeding them into a reader.  Admittedly I am old, but I am not old enough to have experienced what must have been a frustratingly tedious process.  I'm not sure I would have become a programmer if I had been confronted with the tedious business of writing my programs out on paper and then punch out cards. Writing programs back then required a lot of up front planning -- and since computers were expensive and rare, everyone I have spoken to who programmed computers in this manner emphasise that computer time was a limited resource.

It wasn't exactly a process that invited iteration.  You actually needed a fairly good grasp of what you were going to do long before you got around to any of the doing.

Fast forward a few decades and complete religions are erected around the idea of not having the faintest grasp of what you are doing -- but doing it anyway.   You just start writing code, take stock of where you are and then you massage the code some more, iteratively, until it does what you want it to -- or perhaps even something useful you didn't originally think of, but which you ended up doing because the road just took you there.

It really took off a little over a decade ago when all the frightfully boring process oriented people were overrun by the unwashed pragmatists.  People came up with macho names for this recklessness, such as "extreme programming", or worse.  (This is what happens when pale geeks with no upper-body strength read too many fantasy novels).

The 2000s software engineering methodologies can be summarized about "how about we stop talking and just do stuff until it works".  It was a glorious time.

Eventually we arrived at ways of working that departed completely from the realm of computer engineering and landed squarely in business development.  The hip people don't prototype.  They make "minimum viable products".  Which is great if you have absolutely no idea what you are doing business-wise, but appears to lead to questionable software.  Mainly because the focus is on "minimum" and "product" and not so much "viable".  The "viable" is more of a business development aspect.

And that is okay when you are prepared to throw away all your software and start over once your product achieves traction, but sadly, management cultures are striving to catch up.  Managers love the speed with which the illusion of a product arrives -- but few are prepared to face the harsh reality that sets in once you try to "iterate" over a wobbly, chaotic, slapped together foundation.  Management culture is always last to catch up I guess.

But I digress.  I was going to talk about physical objects.

Up until this point, designing physical objects was a bit like dealing with those tedious punch-cards. You needed a plan.  You needed to know what you were doing.  You needed to commit to something and then work long and hard and spend lots of cash to get from idea to mass production.  Because you had to make lots of widgets to eat up the tooling cost -- nobody makes a toilet roll holder with an FM radio and a telephone just to manufacture five of them.

Up to this point, physical objects made from plastics or metal were largely made by people who knew how to design things and who had access to lots of special and very costly toys.  Expensive CAD systems, horribly expensive CAM systems to compute optimum toolpaths, obscenely expensive 5 axis CNC machines to create the molds, materials experts that can pick the right material, plants to do injection molding etc etc.

Process heavy.  Not exactly processes conducive to rapid iteration.

Until affordable 3D printers and 3D design software started popping up.

Sure, 3D printers have existed for a couple of decades now, but their migration into the hands of the unwashed pragmatists has taken a while -- for a number of reasons that are material for several good, long rants.   And while monied engineering firms have used them to do rapid protyping and iteration, these people were largely ... well, engineers.  People who knew what they were doing in the first place.  (Well, that's the general idea anyway).

What we are seeing now is people who have no idea what they are doing rapidly iterating physical designs.  You no longer need to plan when you are going to make something. You no longer need a fully formed idea before starting to build something.  You just do it.  You just start with a flimsy idea and you go from there.  If it doesn't work, you do it again.  You do and you learn.

Iteration is powerful.  If you can iterate fast, it doesn't matter if you start out without a clue and doing all the wrong things.  Because you can try out a bunch of ideas at very little cost and within a very short time-span.

What has happened to software is happening to physical objects.  The universe of people who will be able to design physical dodads is exploding.

(This blog posting was inspired by a recent blog posting by Hans Jørgen Grimstad.  He is building his own 3D printer and he is doing it by iterating.  The XY-axis of his printer is now at revision 87)

No comments:

Post a Comment