The emergence of "instant prototyping" vs. "rapid prototyping"

A couple days ago, I talked about why I liked using and programming modular Linux gadgets. Mike wrote me a long email in response to my comment about "rapid prototyping" vs. "instant prototyping" which I thought I'd share.

With the growing popularity of MakerBot, the reduced transaction costs of interfacing with sensors and digital circuits that the Arduino allows, and the emergence of modular prototyping platforms like Liquidware's Beagleboard-based gadget packs and Bug Labs, it feels like there's been a fairly dramatic increase in single-programmer productivity.

I re-read one of my favorite books of all time, "The Mythical Man Month" by Frederick Brooks. Normally I don't get too excited about dense, heavy, cerebral books that don't have any practical advice unless they teach a new programming language (or algorithm). But in this case, I make an exception, because it's just a decent book that questions the process of engineering.

Well, lo and behold, I decided to amazon around for comparable books, and I discovered that the author has written a new book, which sounded even more cerebral and pie-in-the-sky, "The Design of Design". As an aside, I wonder how much more "meta" you can possibly go. How about: "The Process of Thinking about Writing about the Design of Design" ? I mean, even the Greek philosophers had a limit. (Actually, then you'd need to write a book about a "Formalized Grammar and Metaphysics to Document the Process of Thinking about Writing about the Design of Design.")

At some point, for the sake of humanity, I just hope someone remembers how to actually do something tangible! But I digress. Turns out, I enjoyed the book.

It got me thinking. The Matrix movie got me thinking, as did the movie Inception (actually the 13th Floor did too but fewer people saw that one). So the fact that a book held such high company in my mind as the Matrix, Inception, and 13th Floor is high praise coming from me. Much of the book was focused on the process of designing design processes.

How many designers are too many, how should they work together, how do you organize to solve problems? I had a thought while reading the book: design exists because planning for engineering is an important and valuable step in communication and preparing to optimize problems. This is largely because engineering takes time.

Engineering, or building, or solving problems takes time.

But what happens if you break into a new plateau of productivity? What if that time is reduced significantly?

I've hit a personal plateau and breakthrough in productivity twice. Once in software, once in hardware. The software one happened a few years ago, and the hardware one happened about 2 weeks ago.

Software Productivity

My personal software productivity came when I moved from C programming to purely Perl. I realized that I could write an algorithm faster in Perl, and make a functional program faster, than I could in C. Because of that, I could iterate on the program faster, add new features, in less time. The next bump came when I moved from Perl to R. I could do almost everything I could in C in R, except that R also let me access tons of higher level math building blocks. I became really fast at writing code in R... although it took the code longer to execute, I focused on optimizing the algorithm or the way I wrote a function, as opposed to spending lots of time debugging Perl data structures, or C memory leaks.

The common thread was that R allowed a higher level of functional modularity, but still exposed the lower level functions and data types for me to use when I needed them.

Hardware Productivity

Recently, I've felt similarly faster at building hardware than I used to be. I used to have to write PIC chips into protoboards manually with wires that I stripped and cut myself. Then I got excited about Basic STAMP boards because they let me focus more on the code, and on a few simple digital IO pins. Then the Arduino completely changed the way I thought about accessing sensors, switches, and digital interfaces in general - it significantly lowered the "hardware access barrier" if such a thing exists. In practical words, it let me sit down, and hack the E-Ink screen on the Esquire magazine cover in a matter of hours, rather than days. Now, I'm hacking away on Arduino gadget shields and BeagleBoard Gadget Packs... and the time it takes to go from "I have an idea for a gadget hardware that does XYZ" to actually having one in front of me is measured in minutes.

I think I've found the critical pattern... just like in software, the biggest productivity improvement came as the hardware allows a higher level of functional modularity. I'm interfacing with sensors now, as opposed to I2C buses, so I'm able to build a hardware device even faster using a new sensor, for instance. But the important part is that as the hardware gets higher and higher level, it still gives me access to the basic bit-banging serial and data IO ports and buses, just in case.


Open vs. Closed Design Philosophy

That's the biggest difference in my design philosophy and that of Apple. While Apple *hides* digital IO and obscures interfaces, everything I've ever built *opens* the digital raw interface, and keeps that exposed and really easy to access from Perl, R, and C, even as the modules higher level.

The result is much faster hardware and software development.

As this continues, the time it takes to prototype decreases.

At some point, the time it takes me to prototype a device might reach the time it actually takes for me to just build it anyway.

And maybe that's some new concept or field of "extreme" or "agile" instant hardware prototyping.

...and naturally, this is accelerated by the existence of Open Source Hardware...

Why? Because Open Source Hardware is about lowering design barriers, exposing underlying schematics functional blocks, and the result is that prototyping with Open Source Hardware - in my experience - is orders of magnitude faster than traditional dev kits, and proprietary hardware.

...

Wow. Where did that come from? I suppose this is an example of the kind of high level, head-in-the-clouds type thoughts you walk away with after reading "The Design of Design". I feel like the reading rainbow guy: I recommend that book for any design engineer. I think the kind of design discipline I learned will make me a better hardware hacker - or at least a more efficient one (I wonder if anyone's ever done a study on hacker efficiency?) And the honest-to-goodness truth is that I'm not paid to endorse it. I'm not getting any kick backs (ha), nothing. I simply enjoyed the book, and it made me realize something about my own design process I hadn't thought about before...

Ok, back to hacking hardware, I promise...