Pretty image
The infamous 580-pound, 105-speed BEHEMOTH, with Mac, SPARC, and DOS environments as well as satellite datacomm, HF/VHF/UHF ham radio, heads-up display, head mouse, handlebar keyboard, 6-level security system, speech synthesis, 72 watt solar array, and deployable landing gear to keep the monster upright on killer hills. The bike now resides in The Computer History Museum.

This is the second installment in a series of articles unlike anything we’ve ever published. Steven K. Roberts has figured out how to live passionately, pursuing crazy dreams and building fantastic machines (like BEHEMOTH and Microship, both of which are pictured and briefly described here) and going on amazing adventures. He calls what he does Gonzo Engineering, and in this series he tells you everything you need to know in order to pursue your own crazy gonzo engineering dream.

Formal Tools, Briefly Considered

Sometimes I wish I could claim that Microship development had been a tightly managed progression in which, beginning with a vaporous initial concept, we generated increasingly refined formal specification documents, mapped everything onto a PERT chart to establish dependencies, used that to drive human resources and purchasing departments, then underwent a tightly scheduled fabrication and coding phase focused on milestones and design reviews. That’s how big companies claim to do it... and, hey, we even have some nifty project-management software that knows how to convert TO-DO lists into pretty pictures.

During the BEHEMOTH era, I spent a very interesting afternoon at Trimble Navigation, makers of the bike’s GPS. These weren’t colorful, user-friendly handhelds wrapped around off-the-shelf chipsets back then; they were extremely complex DSP engines coupled with RF hybrid black magic that pushed just about every envelope in the book. I remember being captivated by a massive floor-to-ceiling PERT chart, spanning an entire hallway, the completed boxes bright yellow, the web of interconnections revealing Deep Understanding of the design process and accurate predictions of every step remaining.

“I should do this for the bike,” I mused to my host. “It looks like a great tool.”

“Nah,” he replied. “Project management tools assign resources to tasks. You work alone. Just do something.”

He was right. Even with first-class volunteers and occasional contract help, Nomadic Research Labs is a tiny operation, a de facto non-profit, beset by overload and bad work habits, constantly challenged by such fundamental issues as demotivation, distraction, and lack of funds. A PERT chart in this environment would be masturbatory, and would presuppose a stable design.

Engineering in a Nutshell

What actually happened was much more organic, and I’ve noted with amusement that, despite protestations to the contrary among the engineering population, it’s typical of the way things usually work in industry. Here’s how to manage a huge, complex project:

  1. Accept going in that your first tentative decomposition of the fundamental concept will yield an over-simplified TO-DO list, distorted by misunderstanding of key issues.

  2. Avoiding all the items labeled TBDWL (To Be Dealt With Later) or ATAMO (And Then A Miracle Occurs), dive headlong into the well-defined parts, finishing some of the electronic design so early in the game that it is guaranteed to be obsolete before the physical substrate is built.

  3. Blunder ahead on the non-obvious parts, getting pleasantly distracted by learning curves and occasional moments of certainty, only to discover basic flaws in your reasoning.

  4. Now that you are forced to re-think the initial concept, map it onto newly recognized reality to yield a fresh TO-DO list (with new lab notebooks and computational tools to keep things lively) and another cycle of enthusiastic activity.

  5. Repeat steps 3-4 countless times at varying levels of abstraction ranging from the entire system down to individual components.

  6. Meanwhile, since technology evolves with frightening rapidity, acknowledge the fact that any computer-based system is such a moving target that if it’s not completed quickly, it will be irrelevant by the time it ships.

  7. Respond by simplifying the design, further refining your objectives and abandoning dead-end ideas while doggedly pursuing others that have come to represent too large an economic or emotional investment to allow a graceful retreat.

  8. Compromise here and there, bang out a few things that weren’t on the list, then add them and cross them off to make yourself feel good.

  9. Get totally sidetracked a few times, and periodically dive into major development marathons to meet public deadlines like trade shows, pulling all-nighters in PFD mode (Procrastination Followed by Despair).

  10. Announce new completion dates whenever a previously predicted one has passed, and keep driving your PR engine to maintain interest during a process that is a textbook illustration of Hofstadter’s Law (“Everything takes longer than you expect, even when you take into account Hofstadter’s law.”)

Part of this development heuristic is just sloppy management, but it also reflects the way we think. This is why engineering is, at its heart, an art form (and why the average completion time of a home-built boat is 135 years).

Perhaps the most interesting thing about this seemingly ugly process is that it’s iterative and self-correcting. Grandiose or stupid ideas may not be obvious during first-pass blue-sky analysis (when the project is glued together by wishful thinking), but it’s another story entirely when it all has to be converted into Clearly-Defined Tasks (CDTs) and drawings that make sense to machinists. Without some kind of closed-loop intellectual process to fine-tune your thinking, it would be impossible to get to the point where you can start using engineering tools to convert fantasies into contraptions.

Trying to shortcut this by starting on Day One with formal design methodologies can have the catastrophic effect of committing you to an ill-defined goal state, whereupon the end result is shaped more by your toolkit than by the supposed objective. That’s why so many products seem malformed, patched, and otherwise inelegant: management loves formal methods and looks askance upon such frivolous notions as approaching product design as a delicate blend of art and engineering.

So it appears that designing a system isn’t nearly as rigid a process as typical engineering textbooks would have you believe. Your component choices affect the shape of the thing you’re building; said shape in turn creates constraints that affect your choice of components. Such psychological race conditions can only be resolved by tweaking the granularity knob while adding inputs to your evolving mental model, until the correct solution congeals in a flash.

It’s easy, and here’s how to do it: Prop your feet up on your desk, relax, and form a fantasy of the desired results. Now turn it slowly in your head while calmly examining it from all sides, allowing input variables to float until an unanticipated combination satisfies your psychic fantasy-comparator and generates a flash of recognition. Since all your noodling is saved in a big circular buffer called short-term memory, let this recognition event pre-trigger a snapshot of the conditions that immediately preceded it (before accumulated pondering-propagation delays introduce conceptual drift). There’s your design specification. Take that and run with it!

This is probably not an engineering methodology that makes managers comfortable, though it’s a good summary of life in the trenches. There is a pervasive myth that structured methods and sequential procedures, used in isolation, will get you there... but I’ve never seen it work that way. The tools don’t actually start to become useful until you’re quite thoroughly immersed, and that can take weeks of appearing, to outside observers, as if you are loafing.

boat.jpg

The Microship, the result of an 8-year development project involving extensive sponsorship, students, and volunteer teams. This is an amphibian pedal/solar/sail micro-trimaran with retractible wheels, hydraulic systems, 480 watts of peak-power-tracked solar panels, and zippy performance under sail. BEHEMOTH, the Microship, and the later Nomadness project are all documented at microship.com.

A Sense of Urgency

Speaking of time, there’s another big difference between gonzo engineering and life in industry. Schedules and deadlines, the X-axis of project management, are anathema to the independent worker. Don’t tell me that I have until Monday morning at 9:00 to hand you a report on the solar array thermal retrofit; I’m still in the wall-staring phase on that one and expect to be here for days! I might emerge occasionally to troll the web for prior art to steal, get distracted by other parts of the project, or just say “screw it” and go sailing on a friend’s catamaran in the name of research, but a deadline? Imposing order on the project would send me on a search for something better suited to my interpretation of the term “work.”

Alas, life isn’t like that in a corporate environment, where people actually pay you to behave. Critical-path management, release dates, pre-production prototypes, purchasing cycles, trade shows... there are countless reasons why the long-suffering denizens of cubicles and labs are not given free rein to go with their instincts. But despite the importance of scheduling in coordinating a complex enterprise, there are huge costs involved: design compromises, sneaky shortcuts, employee burnout, kludged patches, bad assumptions, useless documentation, and incomplete testing, just to name a few. This is analogous to sailing: it is well understood that a sailor with no schedule always has fair winds. The people who find themselves calling MAYDAY in a Force 10 gale are usually those who have decided to push their luck for some time-related reason: they’re in a race, vacation’s almost over, the crew has to reach port in time to use a return ticket, or some arbitrary schedule laid out over charts and cruising guides in a cozy den long ago is now affecting the skipper’s judgment.

Working alone and with volunteers on something that will be done when it’s done (and not before), we have the luxury of ignoring the calendar—although with that comes the dangerous temptation to give in to the dreaded BEHEMOTH Effect (“Hey, here’s a cool gadget; let’s see how we can integrate it into the system!”) Somewhere in there is the right compromise, but we are going to assume that when you’re building your life around the Ultimate Project, schedules are not a factor.

Convenient, eh?

Economics

Finally, let’s talk about money. From an engineering perspective, this can be even more annoying than time—there’s nothing like “aggressive cost minimization” to take all the fun out of a design. Fortunately, one of the intrinsic features of passionate dream-chasing is that everything else is secondary, and it’s thus easy to justify spending as much as you have (and then some). Combine this with poverty consciousness, and one can get amazingly creative at scrounging. In addition to all the expensive bits from West Marine and McMaster-Carr, our crazy research vessel contains thousands of parts that were donated, bought surplus, extracted from dumpsters, horse-traded, repurposed, cannibalized, or fabricated on the cheap. But one issue that never came up was worrying about manufacturability and component cost. There’s a sort of certainty here that is immensely liberating:

“This is the most important thing I can possibly be doing, so it doesn’t really matter what it costs to get the job done. I’ll afford it somehow.”

Next up: The Business Angle.

Steven Roberts was the original “technomad,” covering 17,000 miles around the US on a computerized recumbent bicycle from 1983-1991 while publishing tales via CompuServe and GEnie, then extending the same design objectives to water with an amphibian pedal/solar/sail micro-trimaran that consumed all available resources until 2002. As is typical of homebuilt boat projects, however, by the time it was finished he didn’t really want to do that anymore... so he has since made the transition to a full-time life aboard a 44-foot steel pilothouse sailboat, and is now based in the San Juan Islands north of Seattle.

The ship is extensively networked with embedded data collection and control systems, streaming telemetry, and a user-interface layer reminiscent of the Enterprise... with a wrap-around console that includes communications, R&D lab, audio production studio, and a piano. Roberts has published 6 books ranging from travel and adventure to microprocessor design, and prior to becoming a technomad spent a decade developing custom industrial control systems, early home computers, and other paleo-geekery. More on his technomadic projects can be found at microship.com (with the new boat at nomadness.com). He is publishing the ongoing technical narrative of the new project as a monthly PDF “Nomadness Report,” as well as a series of Boat Hacking design packages detailing the subsystems.

Send the author your feedback or discuss the article in the magazine forum.