The Tale of Two Teams: How We End Up With Useless Software
Two equally notorious ways to guarantee failure in any software project:
- Ship too soon
- Never ship
This is the story I use when talking about one of the most common traps in our industry - the false dichotomy between shipping too soon and over‑engineering.
I like it because it’s short, easy to remember, and instantly relatable.
I also like it because, ahem, I’ve been in both camps 😅
Once Upon A Time...
Two groups of software engineers, Team Just-Ship-It-Already and Team Overly-Elaborate-Grand-Design-Committee, were asked to build a device to kill the common house fly.
 |
The product is supposed to take care of this nasty creature. |
1 Day Later
The team Just-Ship-It-Already announced the completion of the product.
"The product has been almost extensively tested. During the tests, in which we mocked the size, movement pattern and speed of the common fly, the device performed with 63% efficiency", the lead engineer commented when asked by the press about the secret to their rapid development process.
 |
A photo of the finished product by the team Just-Ship-It-Already. |
"Suffice to say that we had to make some design and implementation sacrifices to cut the time to market and production costs" he commented briefly on the effectiveness of the product.
367 Days Later
The team Overly-Elaborate-Grand-Design-Committee accomplished the design of the product.
"We wanted a device to not only be effective against the common fly but be as useful in a possible case where the flies, due to possible nuclear experiments, possibly mutate and possibly grow both in size and power." the lead technical architect of the team, while showing a photo of a possible mutant fly, replied when asked why the project took so long.
He, displaying a photo of the "magnificent" design, later commented on the efficiency of the device "well, it's kind of effective against the common fly; you can be sure the fly is dead with the double barrel 155mm cannon, provided that you can aim around the fly; that is if the 3-man crew learned to correctly and swiftly maneuver the 79-ton perfect fly-killing-machine."
 |
The "perfect fly-killing machine" as put by the team Overly-Elaborate-Grand-Design-Committee |
"At this stage, we are looking for more investors to finish the first prototype. We just need to raise another $638 million to get the ball rolling as soon as possible", he replied to a question about when the product will hit the market.
At the end of the conference, he reiterated "It is most important to remember that the owner will be perfectly ready to confront any mutant flies. Even though the probability of a mutant fly is about 1×10⁻²³, one has to be always prepared."
 |
A possibly typical mutated fly as shown by the lead technical architect of the team Overly-Elaborate-Grand-Design-Committee |
Visual Summary: From Story to Practice
At its core, the fable is a warning against both cliffs: under-engineering and over-engineering.
Here’s the “just‑right” middle I try to aim for, and how it compares to those extremes.
 |
| Thin vertical slice of the product delivering a real user outcome. End‑to‑end, viable, observable. This is where you iterate and improve. |
Go Deeper: From Fable to Framework
What you read illustrates the problem. Here are some suggestions on how to approach a solution:
- The Tyranny of Choice: My Case for Opinionated Software Why infinite configurability kills products and how constraints actually increase effectiveness.
- The Zero Incidents Trap: Why Chasing Perfection Backfires How SLOs and error budgets prevent the "79-ton tank" mentality in reliability engineering.
Stay tuned as I'm actively working on this 👆
Enjoyed reading this? Subscribe to my free newsletter, The Engineer's Paradox. Every two weeks, I share behind-the-scenes stories and pragmatic tips that I don't publish on the blog.
Comments
Post a Comment