The Yacht Metaphor for Software Organizations

I’m big on metaphors, and I’ve always loved Joel Spolsky’s software-organization-as-yacht metaphor:

Think of your development abstraction layer as a big, beautiful yacht with insanely powerful motors. It's impeccably maintained. Gourmet meals are served like clockwork. The staterooms have twice-daily maid service. The navigation maps are always up to date. The GPS and the radar always work and if they break there's a spare below deck. Standing on the bridge, you have programmers who really only think about speed, direction, and whether to have Tuna or Salmon for lunch. Meanwhile a large team of professionals in starched white uniforms tiptoes around quietly below deck, keeping everything running, filling the gas tanks, scraping off barnacles, ironing the napkins for lunch. The support staff knows what to do but they take their cues from a salty old fart who nods ever so slightly in certain directions to coordinate the whole symphony so that the programmers can abstract away everything about the yacht except speed, direction, and what they want for lunch.

Management, in a software company, is primarily responsible for creating abstractions for programmers. We build the yacht, we service the yacht, we are the yacht, but we don't steer the yacht. Everything we do comes down to providing a non-leaky abstraction for the programmers so that they can create great code and that code can get into the hands of customers who benefit from it.

“That’s Easy. You Just…”

On a recent Hacker News submission about the phenomenal success of WhatsApp, I clicked through to the comments thread, and read the top comment:

> Why WhatsApp Only Needs 50 Engineers for Its 900M Users

Answer: because sending short messages from A to B is basically a solved problem. There is even a programming language (Erlang) that was made with this application in mind. The prototypical "Hello World" example for Erlang is a messaging application.

There’s some kind of disease in the tech world about trivializing the accomplishments of others, and conversely about understating the effort one took to achieve one’s own accomplishment.

There’s a person I call the “That’s Easy. You Just…” Developer. He wants you to believe that software is easy and obvious.

My Weekend Project

If you’re a regular HN reader, you may recognize the common “Show HN” posts where someone seeks feedback on a project they’re doing. “My weekend project”. People like to suggest that it only took them a weekend to produce the thing they’re now showing off. When you build something in a weekend, it’s typically worth about a weekend’s worth of time. More impressive is, “Look what I built in 10 years.”

Boss, That’ll Take About Five Minutes

In an attempt to win technical arguments, a developer will sometimes trivialize the difficulty of the thing they want: “That’ll take about five minutes.”

As professional developers, we know that nothing takes five minutes to ship and recognize the exaggeration for what it is. The problem is, non-technical people hear this trivialization and occasionally take it to heart. “These guys keep talking about how that would take ‘about 5 minutes.’ Software is pretty easy, I guess.”

Cheating on the Definition of Done

A common hack is to cheat on your definition of done. Despite your overall feeling of Scrum as a methodology, I think one thing they nailed is the importance of getting precise about the definition of done.

Rule of thumb: a flurry of code at 2AM usually does not result in something that’s done.

Obviously…

It’s easy to pretend that something you know now was obvious. I’ve given in to the temptation to treat a momentary advantage in knowledge over someone as an opportunity to pretend that knowledge was obvious to me all along. In fact, I still feel like a jerk looking back at the times I’ve done this. “Oh you need to do X, just use Y. Duh.”

It’s okay to admit that things are hard, that maybe you felt dumb yourself when you were learning it. The secret is, we all actually know it’s hard, but we won’t admit it.