Nomadness

The bulk of this post is an excerpt from Issue #14 of the Nomadness Report, which is finding its voice and shaping up well (with a compilation of the first 12 issues now available as an eBook). Much of the content in these early issues is context-setting, both in terms of the recently changed facilities scene and the overall project objectives.

It was in the latter spirit that I found myself discussing the mental model necessary to take on something so insanely complex. Companies handle this sort of thing by creating a hierarchy of departments and design groups, but I’m working more or less alone on this tour de force of geekery… and that is frankly overwhelming. I have already lived through some of the risks of this: watching completed systems become obsolete while spending years building the physical substrate that should have come first (Microship), getting seduced by gizmology and letting it overwhelm issues of usability (BEHEMOTH), diving into design without a clear internal “elevator pitch” to keep things focused (Shacktopus), buying gadgets long before they are really needed and then watching them go stale on the shelf (Nomadness). If it weren’t for the existence proof of well-executed successful projects (Winnebiko, Winnebiko II, Bubba, & Polaris), I’d start to worry…

So now that all the logistical impossibilities have been resolved and my lab is right at the head of the dock, I’m in the unfamiliar position of being able to work full-time on the Nomadness project. It’s almost like starting from scratch, though the design goals are already clear; I’m treating this fresh perspective as an intellectual luxury and making a deliberate effort to avoid the panoply of deadly phenomena cataloged above.

I thus opened the latest issue of the Nomadness Report with a philosophical piece on designing a complex system. Reader feedback has been most gratifying, so I decided to reproduce it here in its entirety…

The Perils of Segmentation

As the conceptual components of this daunting project have been shoved to and fro over the years, they have by nature become segmented… and here there be dragons.

Imagine all the arbitrary boundaries and overlaps. Power is a good example: it’s one big chunk that has always been on my radar, further broken down into Battery Management and Distribution. But if you really think about it, both of those are woven so deeply into the rest of the ship that any attempt to draw a box around them immediately carves out (or calves off, depending on your perspective) sub-categories more logically associated with other systems.

This may not sound like an important issue, and indeed there are clear enough “edges” when it comes to physical panels and schematics that I don’t spend much time fretting over ephemeral classification ambiguities. But it still leads to a sort of sloppiness in the project-management domain: is this piece of the puzzle a packaging task, a power distribution job, or just the upstream DC connection to that subsystem over there?

It may seem that the more neatly I can parse this huge system into a tidy hierarchy, the easier it will be to visualize… and thus, to build. But not so fast.

Fundamentally, what we are talking about when designing any huge interconnected system is the need to reduce complexity. If a project has the opposite effect, then it ventures into the domain of wankage – cool in a geek sense, but not very helpful when it comes to effective day-to-day operation.

It does not follow that a segmented design process will necessarily yield a choppy user experience, but things do have a tendency to go that way despite our best intentions (I’ve done it). The components take on lives of their own, with their various interfaces and affordances defining our view of them… as well as the way they interact with each other. Indeed, we must think of things with this kind of object model, lest the entirety turn into a giant mass of spaghetti.

The problem is that a complex system presents design challenges at every level of magnification. This easily translates into a “sliding scale,” with one extreme a well-conceived object-oriented chunk of code (where development tools and geek-cultural norms enforce discipline). But when you step back from this utopia of bits, you find a box with hard edges and arbitrary behavior, nestled into a complex application environment that incorporates not only other subsystems developed in parallel, but multiple incarnations of unrelated concepts from third-party vendors, orthogonal cultures, previous technological generations, cobbled gizmos of necessity, and random glue.

Suddenly the elegance of the Big System is a function of the level of magnification with which you approach it, and, well, that’s just confusing.

Nightmarish Imaginings

On Nomadness, this phenomenon might manifest itself as an elegant yacht with traditional user-interface affordances (lines, pedestal, winches), augmented by a complex multi-generational aggregation of marine electronics: chart plotter, autopilot, nav/weather instruments, radar, power systems, engine controls… interfaced, if at all, via a melange of protocols new and old. In the background is a panel of circuit breakers, and scattered here and there are little control panels, valves, through-hulls, and stand-alone electronic modules… none particularly well documented.

Added to this, thanks to years of obsessive effort reflecting designs and purchases scattered along the timeline of a rapidly evolving industry, we might find a second technological overlay: a console system in which are embedded a variety of radios, computers, networking tools, audio production gear, lab equipment, and homebrew gizmology… along with a database-backed server with a dozen or so nodes around the boat contributing data. Atop all this (assuming I get around to it while still alive) is a rich layer of software intended to bring it all into a single conceptual space.

And it’s all intended to reflect the dream of a cohesive integrated system, reminiscent of the starship Enterprise. “Computer… report!”

OK, what’s wrong with this picture, other than sounding like something that will never get finished?

An Experiment in Conceptual Cohesion

A key component of my work on previous technomadic substrates (most notably, BEHEMOTH) has been the avoidance of wheel-reinvention through the expedient of taking one product after another and incorporating them into a general toolset. This typically involved serial and audio crossbar networks, hacking power supplies and original manual controls to allow load shedding and software-driven operation, and otherwise shoehorning a diverse range of gadgets into a single environment.

That’s pretty much what I’m doing here, and in some ways it’s easier now… most of the gadgets that I need have better tools for remote control than their counterparts of a quarter century past. With a signal-agnostic crossbar network and a bigger power budget to accommodate things that need an IP stack, it should not be too difficult to make anything talk to anything.

But here’s the problem: all that is limited to my own geek overlay onto the existing ship. Naturally, that will incorporate the NMEA2000 network and I/O from independent subsystems, but one of the biggest chunks of this whole project boils down to plain old interfacing: using Arduino nodes and trivial sensors to bring everything under the aegis of the central server (see the “Shacktopus Overview” in Issue #3 for more context). I’m not fundamentally changing the design of all the systems made by other people, just slurping them into my microworld.

This is a considerable oversimplification, though it appears to be the solution to the problem: interface the hell out of everything, wrap it in code, and cast off the docklines with a tablet-based GUI added to the list of traditional yacht affordances. Tighten that winch. Head up a few degrees. Pinch to zoom that video image from the masthead, and verbally inquire about the ETA at our next waypoint.

But let’s look at how all this impacts the development process, including the ongoing maintenance issues of replacing ailing or obsolete subsystems. If we get to control every aspect of the design, then this would not be a problem… but I am annoyingly finite, and would not reinvent all these arcane wheels even if I had the time and skills to do so.

Back in the Microship epoch, I developed my network of controller nodes in FORTH… a lovely vocabulary-based language that embodies a “bottom-up” programming methodology that makes testing trivial and enforces clear chunking of functionality. I found myself adapting the same philosophies to hardware design, trending toward clearly defined circuits that do one thing well and have precise interface specifications.

We don’t have that luxury when trying to assimilate huge complex systems made by other people… so the broad character of this project is starting to emerge: All we have to do is become intimately familiar with every system (both now and in the future), write the tools to bring it into our current paradigm, create new hardware for every un-augmented device or data point of interest, create a database standard and a metaphor for dealing with this “internal model of the ship,” and cobble interface code that works from every connected device ranging from tablets and phones to voice and packet radio. All that, and packaging too.

No problem.

Single-System Perspective

This convoluted philosophical sketch brings us back to the point of this article: if we’re going to take on something this absurdly ambitious, it is essential that we think of it correctly. If there is an attempt to accomplish all this by outlining a collection of isolated to-do list items, each defined by the flavor of the target device and the software tools du jour, then it is going to be nigh impossible to avoid a gradual emergence of the scenario I imagined above… so many different concepts in the same system that I can neither keep it all in my head nor successfully document it.

The solution, I believe, comes down to the way every task is contextualized. This almost sounds like HMB (Hip Metaphysical Bullshit), but it’s true: when we build machines, they become the crystallization of our dreams. Get the dream right, avoid letting the tools shape our work, and keep the big picture in context… and we at least have a shot at creating something that reflects our design objectives.

What does this mean in pragmatic day-to-day terms as I resume focus on the boat? Just this: Nomadness (or any huge convoluted system) is not a collection of subsystems as much as it is a single entity. The temptation to treat the project as a massive hierarchy of stand-alone sub-projects is dangerous, for the inevitable conceptual drift will change the flavor from one to the next. The solution boils down to two things:

• Keep a clear dream uppermost in mind, even if that requires reducing it to an “elevator pitch” so it is not vulnerable to creeping featuritis.
• Make sure every task is colored and shaped by that dream, and is not allowed to wander off into the seductive domain of its own intermediate objective.

Let’s put a practical spin on this, then get back to specifics!

Engineering in a Nutshell

This little snippet about how engineering really works was from my aborted Inside Microship book a decade ago, and is still annoyingly relevant. 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 homebuilt boat is 137 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.  The exceptions, when they occur, are a joy to use. The rest miss the point, no matter how stylish their exterior or sophisticated their underlying technology.

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 naturally 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.

Nomadness Report eBook is $10 in my online store (27.6 megabyte PDF)

Nomadness Report subscriptions are $20/year (38 cents an issue!)

I suppose it is ironic for a paleo-technomad to look at something as mundane as moving and note that it’s personally epic.

But epic it is, after 13 years in a place that was created for the high-energy Microship project… fabulous facilities that were perfect at time but are now too far from my nautical substrate du jour, haunted by the swirling ghosts of relationships past, and cluttered with the echoes of yesteryear’s hackage.

I’ve known this for a while, held captive by spacious digs that make geek friends envious, complete with an award-winning house nestled against a sylvan backdrop that outshines many a State Park. A few times over the years I went on quests for moorage and lab facilities integrated with a home base, but nothing ever pushed all the right buttons until this one.

We’re now ensconced in La Conner, with Nomadness parked at a dock just below our verandah, an upstairs apartment, a ground-floor lab of about 2000 square feet, and indoor parking very close for the mobile workshop for messy stuff. Here’s the dinghy’s-eye view; our building is just past the boom:

The move is gradual, and is a very effective filter. Tonnage that I haven’t felt the urge to haul must not be very important, so it’s getting easier to let dormant items go. And with tourist traffic past our “storefront” every day, a free cart is parked outside, laden with items irrelevant in the context of open-ended adventure: dead media, old books, dated electronics, kitchen clutter, cast-off gear, cruft, gewgaws, and minutiae. Every day, things magically disappear, leaving little breaths of fresh air in the dusty attic of my brain.

This isn’t a bad place to be. The Swinomish Channel is our front yard, always changing, reversing direction, carrying traffic ranging from drool-worthy yachts to doddering fishing boats. We even get out in our kayaks on occasion; here’s Kirsten enjoying the maiden voyage of Trinket:

The Anarchivist

Speaking of yesteryear’s echoes, there is one category of stuff that has been weighing on me for some time: the mountain of bike-epoch media binders and video dubs of my various TV appearances over the years. Obviously I have to keep it all… but in the form of musty tearsheets and slowly degrading VHS tapes? I don’t think so.

I’ve started a new corner of the website: The Microship Anarchivist. This is another WordPress blog, but instead of random noodlings and project updates like this one, it is devoted to articles, historical records, project documentation, and media coverage. The fun thing is that each post carries the date of the original, so it’s forming a timeline that can be browsed sequentially.  At this writing, there are only about 20 posts there, but the mountain is high (and the process fun).

For print media, I use the Fujitsu ScanSnap to acquire page images direct to Searchable PDF. I thought I was going to have to do multiple scan passes to get this along with images and OCR’d text, but not so: the trick is to use Automator on the Macintosh to produce the secondary files. Whenever I have a new article PDF, it takes just a few moments to set the metadata, create a JPEG image of each page, and extract text to a vanilla file.

The most time-consuming part is stripping hard returns, removing end-of-line hyphens, and rearranging any stray captions or sidebars. When that’s done, I create a new blog post, write a quick intro, insert a magazine cover photo if appropriate, then paste in the text with page images as small insets down the left side.

Pulling some of these old documents out of the vault and getting them online is a hoot, and not just my own retro-geekery. One of my favorites is the 1939 recommendation letter by St. Clair McKelway, the editor of the New Yorker, helping my mother get accepted into the Barbizon.

The videos are another process, and it feels good to rescue these bits of history from slowly degrading VHS. I have a Panasonic digital camcorder that I chose a few years ago because it was capable of recording from an NTSC source, so I’m using it and an old VCR to dub the tapes. The video is then slurped into iMovie HD via Firewire, compressed appropriately (still twiddling those knobs in search of the size/quality sweet spot), and uploaded to YouTube. The first one, a CNN piece about Winnebiko II from 1988, can be viewed either there or embedded in the anarchive page.

All this will take a while, but it’s a nice short-attention-span background task. I’m already finding the resulting timeline (though still sparse) to be useful. One of the other highlights is the full set of schematics from my 1974 homebrew computer (now in the Computer History Museum).

The Nomadness Report

It is strange to think that current work will one day be just as quaintly anachronistic as all that, but we might as well enjoy the sparkle while it lasts. Boat project details are primarily covered in the Nomadness Report, subtitled “A Weekly Compendium of Boat Hacking and Gonzo Engineering.”

This is proving to be an interesting publishing venture, with lots of subscribers and 11 issues as of this date. Each one is a PDF of 5-10 pages, sometimes with a major technical feature, other times with more of a magazine flavor. (Issue #5 is free, and is all about the Polaris mobile lab.) The fun thing about this is that the material can drop right into a compilation… the first of which will take place as soon as Issue 12 is completed.

These will be available as ebooks, of course, but I’m also going to use MagCloud to produce a glossy hardcopy edition. Here’s the pricing:

• 1 year (52 issues) of the Nomadness Report: $20
• Quarterly compilation ebook (12 issues): $10
• Quarterly hardcopy magazine edition: $20

I took August off due to real-estate adventures and other logistics, but am diving back in this week. As the new publication continues to unfold, I’ll be welcoming participation by other boat hackers and nautical geeks… please let me know if you’d like to contribute something about your work.

Current Nomadness Projects

All this writing is fine, but what about the real stuff? Time lost to logistics pretty well killed off this year’s vague cruising plans, but we’re looking toward a long season up the Inside Passage next year and a 2013 departure for open-ended voyaging. I’m not keen on paying rent forever, so there’s a strong sense of the clock ticking (not to mention the slow horror of growing irrevocably older and being reminded that we better get on with it).

There are two broad categories of projects. The first includes essential integrated systems, maintenance, plumbing, coatings, power, and all that other basic boat stuff. The second is the übergeekery, most of which is centered in the 8-foot wrap-around console assembly that will be staged in the new lab and then installed in place of the old dinette forward of the pilothouse.

The boat essentials are more critical for being able to get out there and enjoy life, of course, so they have priority… at the moment, I’m reverse-engineering the Yanmar engine control panels so I can debug the sudden-onset engine alarm that woke up everybody but me at about 5 AM a few weeks ago. The drawing will join others in my new 11×17 documentation binder, such as the one that I did recently for the Waterworks system (click to embiggen):

Once this is done, I’ll turn my attention to the new integrated power console, which will convert the awful unserviceable area of the old AC panel into a pantry across from the galley while tightening power management into a single clean layout at the inside helm.

This Blog…

I’ll continue posting updates and adventure tales here… along with occasional details of the systems as they come together. The more substantial tech material will be in the Nomadness Report, but I’m keeping this blog alive for lighter geekery and sea stories. Thanks for hanging on during this long and turbulent tack; it should be getting fun again as soon as we come about!

Cheers and fair winds,
Steve

The move to La Conner is now about half-complete, with the Camano house empty and the lab still cluttered. New facilities are online and working well, and when the relocation is complete I’ll give you a proper walkthrough. Already I’m noticing that there are no more excuses… lab, shop, office, home base, and all the rest are now right at the head of the dock where Nomadness is berthed!

The Nomadness Report is going very well, with the first compilation (both eBook and print) coming when we pass the #12 milestone.

This post is just a quick update to provide a link to the boat’s webcam, which is now back online with a faster update rate and a view across the channel to the Swinomish Reservation. This is timely because the Paddle to Swinomish 2011 is taking place July 25-31, with over 100 canoes from tribes all over the Pacific Northwest converging on our tiny town along with an estimated 20,000 visitors. I thought you might like something more interesting on the camera than a static view of the Nomadness interior or the adjacent shore, so I strung cable over to the starboard side and parked the Axis 210 in the window. The next issue of the Nomadness Report will detail the webcam installation.

Here is the Swinomish Channel webcam

(Embedding within WordPress apparently takes some widget installation, which I don’t want to deal with at the moment… hence the lazy link!)

Cheers from Nomadness,
Steve