Skip to content
DevMeme
When continuous pivots turn the MVP into a ship-car-plane-reindeer hybrid
Agile Post #121, on Feb 14, 2019 in TG

When continuous pivots turn the MVP into a ship-car-plane-reindeer hybrid

Why is this Agile meme funny?

Level 1: The Dog Pulling the Boat-Truck

Imagine asking someone to build you a skateboard. Halfway through you say "actually, make it a boat." Then "can it also fly a little?" Then "keep the wheels though, Grandma liked the wheels." Nobody ever gets to throw away the old parts — they just keep gluing new ones on. In the end you have a truck-boat-airplane-sled stitched together like a teddy bear that's been repaired too many times, named Hope because all the better names got crossed out, and the only thing pulling it is one tired little dog wearing fake antlers. It's funny because the builders aren't even angry anymore — they just shrug and say the changes were "minor," the way you'd say a tornado "rearranged" your room.

Level 2: Specs, Pivots, and Why the Jet Engine Stays

Key vocabulary, as illustrated by the contraption:

  • Spec (specification) — the written description of what software should do. When the comic says specs suffered "minor changes," it means dozens of individually small requirement edits whose cumulative effect is a different product entirely. This is scope creep: no single change seems worth pushing back on.
  • Pivot — a startup term for changing the core product direction (the crossed-out ship names). A clean pivot replaces the old thing; a real-world pivot usually wraps it.
  • Deprecated — officially marked "do not use anymore, scheduled for removal." The joke of the DEPRECATED jet engine is that deprecation is a promise of removal, and promises don't free up sprint capacity. Early in your career you'll grep a codebase and find @Deprecated annotations older than your tenure.
  • Versioning (V1.1, V1.2, V1.5, V2.1) — labels tracking how software evolves. Here different parts of one product are at different versions simultaneously, which is exactly what legacy systems feel like from the inside: the login flow is from 2014, the billing module is from the 2019 rewrite, and they share a database neither fully understands.

When you inherit your first legacy codebase and ask "why is there a SOAP client in a GraphQL service?", the answer will be some version of this comic: each layer made sense when it was added, and removal was always someone else's next quarter.

Level 3: Archaeology of a Franken-Ship

This MonkeyUser comic, titled "PIVOTING", is a complete software architecture autopsy disguised as a vehicle. Two stick-figure developers gaze at the result while one delivers the punchline with the flat affect of someone reading from a postmortem:

THE SPECS SUFFERED MINOR CHANGES OVER TIME

Every component is a fossil from a different strategic era, and the version labels make the stratigraphy explicit. The blue truck cab is stamped V1.1 — the original product, the thing someone actually pitched to investors. It's stitched to a wooden pirate-ship hull with visible sutures, the comic's perfect metaphor for an integration layer: two systems that were never meant to coexist, joined by whatever adapter code could be written before the next demo. The hull carries portholes labeled V1.2 and V1.5, a steamship funnel marked V2.1, an airplane wing, sled runners, and — the sharpest detail in the whole drawing — a jet engine literally labeled DEPRECATED, still bolted on. Everyone knows it shouldn't be there. Nobody dares remove it, because nobody is certain what still depends on it. That is technical debt in its purest visual form: the deprecation annotation exists, the deletion never happens.

The ship's name tells the product-management half of the story: SANTA M..., CONQUE..., and LASTR... are crossed out, replaced by HOPE. Three rebrandings — three pivots — each one a steering committee deciding the previous vision was wrong without budgeting the time to unwind it. The new direction is always additive: keep the truck (a customer still uses it), add the hull (the new market), keep the funnel (a contract requires it), bolt on the wing (the CEO saw a demo at a conference). The result is a distributed monolith of requirements — each spec change locally reasonable, globally incoherent.

And then the payload-to-propulsion ratio: this multi-modal land-sea-air contraption is towed by a scrawny dog wearing tied-on antlers. That's the team. Headcount was sized for the truck; the org never re-sized it for the ship. The antlers are the motivational all-hands where the dog was told it is now a reindeer. The green pirate bug mascot perched on the bow with a sword — MonkeyUser's recurring bug character — isn't even hiding. At this level of architectural entropy, the bugs ride shotgun and have seniority.

The systemic truth being satirized: pivots fail not because changing direction is wrong, but because organizations pivot the roadmap without pivoting the codebase. Deleting V1 is a quarter of "negative" productivity no one will approve, so V1 stays, sutured in, deprecated but load-bearing, forever.

Description

Single-panel comic titled “PIVOTING”. Two stick-figure developers stand on the left; one says, “THE SPECS SUFFERED MINOR CHANGES OVER TIME”. Filling most of the frame is a ridiculous vehicle composed of mismatched parts: the rear is a blue delivery van labelled “v1.1”, “v1.2”, the mid-section is a wooden fuselage with three portholes and scribbled version tags “v1.3”, “v1.5”, while the bow is a pirate ship renamed multiple times - crossed-out text reads “SANTA FIT”, “CONQUISTADOR”, finally “HOPE”. A large smokestack marked “v2.1” sticks out of the deck, a jet engine stamped “DEPRECATED” is bolted to the roof with a torn red flag, and a lone reindeer strains to pull the whole contraption. A tiny green pirate frog waves a cutlass from the bow. The mash-up visually represents runaway scope creep, ever-changing requirements, and technical debt that accumulates during repeated product pivots familiar to software engineers

Comments

7
Anonymous ★ Top Pick After twelve pivots we’ve got React wheels, a COBOL hull, a deprecated jet engine for “infinite scale,” and one cron-job reindeer pulling it all - pretty sure Gartner calls this pattern “Franken-as-a-Service.”
  1. Anonymous ★ Top Pick

    After twelve pivots we’ve got React wheels, a COBOL hull, a deprecated jet engine for “infinite scale,” and one cron-job reindeer pulling it all - pretty sure Gartner calls this pattern “Franken-as-a-Service.”

  2. Anonymous

    The only ship where "backwards compatibility" means it literally goes backwards, sideways, and occasionally airborne depending on which deprecated API you're calling

  3. Anonymous

    Every 'minor spec change' is minor in isolation; integrate over two years and you get a truck-boat-plane named Hope, towed to production by a dog in antlers

  4. Anonymous

    Ah yes, the classic 'minor changes over time' - where your microservices architecture somehow evolved into a wooden boat on truck wheels powered by deprecated V8.1, held together by hope and crossed-out project names. At least the green circle in the porthole suggests one service is still healthy, which is better than most legacy systems I've inherited. The real question is: do we refactor the entire ship or just keep adding more wheels until the next pivot?

  5. Anonymous

    Pivoting: where 'minor changes over time' silently refactor your clean MVP into a legacy monolith that even Santa can't deploy on Christmas Eve

  6. Anonymous

    PM: “Minor changes to the spec.” Engineering: cool - now our product violates SemVer, Conway’s Law, and the laws of physics; the rocket’s deprecated and the event bus is literally a reindeer

  7. Anonymous

    Nothing says “minor spec changes” like a car‑boat‑plane‑sleigh monolith with a deprecated engine and a v2.1 sticker - Ship‑of‑Theseus‑as‑a‑Service

Use J and K for navigation