Don’t build. Compose.
You’re writing a novel, not constructing a bridge
I was driving over the Bay Bridge recently while thinking about the product our company is developing, and trying yet again to somehow map the wild and woolly world of developing software to what feels to me to be the dominant paradigm people use in their mental model of it: civil engineering. It's everywhere in the language: we study software engineering, we do nightly builds, we think about our product architecture.
The only problem is that it doesn't match with anyone's experience. You don't usually feel like you're “building” a product at all. There are no blueprints. During development, you're often still learning what kind of bridge your customers want, and in fact whether they want a bridge at all (some would really prefer a tunnel, and others think a helicopter might do the job best). We all know this, and that's why we all have those funny comics by our desks that show what the customer asked for (a nice tire swing) and what the product team delivered (some rope tied around a tree with a board attached to it).
So, here's the insight I'm currently tossing around in my head: The problem is that software isn't built; it’s written. The final product is not like the Bay Bridge. It's like a novel.
Engineers are the authors. They start with an early draft (sometimes known as a prototype), an idea of the main characters (features) and the arc of the plot (use cases). They write a few chapters. They learn how the characters are acting and whether things are moving in the right direction. Then they go back and tweak the storyline a bit. They iterate.
Product managers are the editors. They help the authors think through the broad themes that the novel is trying to communicate. They make sure that one chapter flows into the next, and that the pacing is right. They look at the overall aesthetics of the work -- the language used, the typesetting and format of the pages. They iterate.
Perhaps most importantly, the authors and editors need to work together to determine when the novel is finished. Unlike a bridge, you never put in the last rivet and make the last weld. You can always revise a novel. The question is, will the novel be better or worse off for the change?
Product development is an art, and not a science. And the way to process improvement is to think in terms of how our teams can work together not to build a better bridge, but to write a better novel.
—
P.S. It’s interesting to note how software itself has evolved over the decades from a bridge to a novel, as user experiences with software products have moved from being rote and mechanical (the ENIAC missile trajectory calculator) to more open-ended, flowing, and emotional (instagram). This trend will only increase as technology becomes more immersive and integrated into the fabric (and story) of our lives.
