How Weak Analogies About Software Can Lead Us Astray

I often have conversations with CEOs of software companies or software-powered (ecommerce) companies who aren’t steeped in how software is designed and built.  They come from the sales side, finance, or are subject experts (veteran recruiters now running recruiting software firms).  Understandably, they tend to apply analogies from more familiar business contexts to the creation of software.  But this takes us in a wrong direction if the analogy doesn’t work.  Let’s unpack two.

“Building Software Is Like Building Cars”

Most of us have seen pictures of an automotive assembly line.  Parts are sourced from suppliers or other plants, each step is carefully choreographed, robots increasingly take on repetitive tasks, and the factory runs like clockwork.  The key metrics are throughput (cars per line per hour) and cost (per unit gross margin, burdened manufacturing cost) and quality (manufacturing defects per million units).  The plant staff has tons of skills and expertise, mostly focused on making the car-building process as predictable as possible.

Henry Ford popularized the assembly line and 40-hour work week even though he didn’t invent the gas-powered car and never said that thing about faster horses.  Sounds like a great model for building mission-critical software.  Here's where that gets us into trouble...

(a) All of the design and core automotive engineering happens separately, before a new model is put into production.  When we look only at the factory, we’re missing the entire R&D process.  It may take 3-5 years for a traditional car company to conceive, design and test a new car before the very first production unit rolls off the line.  Plus decades to commercialize new technology.  Toyota spends about $10B/year in R&D; Ford spends about $7B.  They do their best to lock down every single detail before their annual plant retooling because changes during production are hugely expensive.  Engineering mistakes can lead to costly and life-threatening recalls.

That’s a poor concept to borrow for software development.  It harks back to the 1970’s waterfall model — when we imagined perfect specs written by a handful of brilliant architects/designers, then handed off to armies of generic coders who perfectly implemented those specs.  Except for the most trivial tasks, I’ve never seen this approach produce good results.  In fact, a perfect spec that anticipates every possible situation or error condition looks suspiciously like the code itself.

Instead, software development/design teams are simultaneously understanding problems while solving them.   The team makes dozens of choices every day, ideally informed by business objectives and user testing and applied architecture and data cleanliness.  (And product management opinions.)  We have broad goals, but concocting a perfect development plan is nearly the same as doing all the development work.

Likewise, UX design frameworks are usually interpreted by team-level designers to fit the problem at hand.  We’re constantly trading off consistent look and feel across the application suite against what will help users at this step.

So in the software business, we’re usually solving and designing and implementing and fixing all at the same time.  The hard part isn’t the typing, it’s the thinking.  (The course of true software development never did run smooth.)

(b) Physical manufacturing profitability is all about per-unit margin.  The essential cost of building cars is in the materials and manufacturing labor, not R&D.  Eliminating one door fastener or one assembly step is a good use of R&D/Engineering, because we can save $16 each on 4M cars.  New car designs start with a price (MSRP) and cost target: we must make positive margin on every unit.  The pressure to lower manufacturing costs is tremendous.

But software profitability is all about selling the identical software bits thousands of times without changing them.  Done right, creating software is mostly a fixed cost (per time) endeavor: every additional license or download or transaction is close to 100% margin.   The most important financial metrics are break-even (“how many licenses do we need to sell to cover our development team?”) and time-to-value (“how quickly can we add more users faster, with the least possible handholding or customization or intervention?”).

And software pricing is based on end customer value, not on our effort.  Customers don’t care about the size of our development team, or how hard they work, or whether we like scrum or Kanban or XP or AgileFall.  They pay us based on how much our software will help them make money or save money or reduce business risk.

So hiring junior developers or offshoring to lower the average engineering rate misses what’s most important.  Crafting better software should get us more customers and make us more money.  Small teams of empowered developers/designers/product managers with deep understanding of real customer problems will out-earn large teams doing contextless color-by-number implementation of specs.  The intrinsic quality of the work matters, which is lost in a command-and-control organization.

(c) New car models mostly come out annually.  Options, colors, engine sizes and trim are decided and priced before they hit the production line.  Car buyers who want a unique sunroof or stereo or paint job pay for after-market customization.  (What’s standard in a 1955 Bel Air Chevrolet?)

This is changing somewhat as the software content of vehicles soars.  Tesla can deliver new features through software updates, but traditional manufacturers only do this for recalls and safety issues.

In contrast, every software team has an infinite backlog of requests in all shapes and sizes.  Customers expect us to continually fix bugs, improve security, simplify workflows, scale up capacity, add integrations, and deliver delightful new features.  They assume that new stuff works without disrupting anything already in the product.  Weekly updates seem barely sufficient, and we constantly worry that new features will destabilize existing stuff.   This looks nothing like the annual automotive hype cycle.

“…Is Like Building a House”

Our layman impression of building houses is each is planned, predictable, implemented perfectly from the architect’s drawings, and delivered per cost estimates.  That they’re all made out of ticky-tacky and they all look just the same.  But anyone who’s been through a major home renovation knows it can be an expensive comedy of errors.

Recently, I talked with a construction expert-turned-CEO of a building-related software startup who knows better.  She reminded me about permitting delays, construction labor shortages, materials and supply chain issues, volatile lumber prices, and clients who want to add one more bathroom at the last minute.  Completed buildings need “as-built” plans showing exactly what was implemented since that almost never corresponds exactly to the original architectural drawings.  And the cost of errors can be catastrophic.

So physical buildings are conceptually simpler than enterprise software, but may be not so easy to forecast.   (Hmm.  Maybe this is a decent analogy after all.)

How About Some Alternatives?

Success in the software product business is all about volume and scalable revenue.  Have we built something that the millions of consumers or thousands of companies will be motivated to pay for?  On-time/on-budget delivery isn’t as important as usage or ARR or unsolicited word-of-mouth.  Customers don’t care how hard we worked or the size of our development/design team, or which time zones our product managers live in.  Instead, they care if it solves a real problem for them.

So perhaps this looks more like movie or stage musical production.  Pre-COVID, “Rocketman” outearned the 2019 “Cats” movie 20X on one third of the budget because audiences loved it and told their friends.  No one remembers if it delivered on time.  Hamilton has made $1B to date and Spider-Man: Turn Off the Dark lost $75M even though they are about the same length with similar numbers of songs.  Turns out that movies/musicals need brilliance and great design and audience surprises (plus a sprinkle of luck) as much as deadlines and budgets.

And an experienced staff matters.  Cinematographers get academy awards because their work really shows (even though we don’t see them doing their job), and first-time cinematographers rarely get it right.  Studios pay a lot of money for deep functional expertise: producers, editors, casting directors, set and lighting designers, stunt teams, and intimacy coordinators.
Tying that back to software economics, we should be hiring the best architects and designers and test automation engineers (rather than the cheapest) to up our odds of success.  The market rewards value, not effort, so smart CEOs want a mix of pricey veterans and enthusiastic novices.

Sound Byte

Software isn’t yet an assembly line business.  It’s still as much craft as mechanics.  When we focus on delivery dates and staff costs to the exclusion of talent and astute solutions, we ship indifferent products instead of hits.  Comparing that to automotive assembly lines isn’t so useful.