The Difficulty of Designing IT Architecture: Lessons from the Boat Joke
There’s an old management joke about a rowing competition between a Japanese and a Dutch team. The Japanese, lean and synchronized, have eight rowers and one coxswain. The Dutch, meanwhile, have two rowers, a manager, an agile coach, and a few middle managers. Unsurprisingly, they lose badly. Afterward, they hire consultants, reorganize, and add a coffee machine for motivation — but the next year, the result is the same.
The humor hits because it’s absurd — but it also captures the essence of how IT organizations work: lots of structure, little alignment, and constant tinkering instead of redesign.
There’s another joke about boats: A customer orders a custom yacht. It arrives perfectly finished — except for one small problem: it sinks. When the customer complains, the builder shrugs. “We built exactly what you asked for.”
How often have we heard the same line in IT? “It wasn’t in the user story.” These jokes get laughs because they’re ridiculous — and yet, they describe how much of modern IT is built. Teams race toward delivery, feature by feature, sprint by sprint. The finish line is always in sight, but the direction is never questioned.
The boat joke teaches us to stop focusing solely on the finish. True quality isn’t about “does it work?” — it’s about how efficiently, coherently, and sustainably we get there. Tests, reviews, and metrics measure outcomes, but only understanding the problem makes the boat itself explicit.
And somehow, despite everyone knowing this, we keep designing as if the shape of the boat doesn’t matter. Or maybe it’s because there is no second boat — no reference to compare our design against.
The Missing Second Boat
Here’s what the old management joke really exposes: In most IT projects, there is no reference boat — no other implementation of the same system to compare our design decisions, performance, or maintainability against.
In business terms, every project is a “one-boat race.” If it works, it’s considered a success — even if it barely floats. Without a reference, inefficiency hides behind perceived progress.
It’s tempting to think this problem is unique to software, but it extends to infrastructure and hardware as well. You can compare firewalls, storage systems, or cloud platforms all day long — benchmark them, list their specs, run synthetic tests. But those comparisons only tell you which performs better in isolation. They say nothing about how either performs in your architecture, with your data, your team, and your operational constraints.
Even infrastructure rarely has a true reference boat. Each environment is a custom blend of assumptions, people, and processes. So “better” becomes subjective — it’s not about which firewall or database performs best in theory, but which one fits your river, your current, your crew.
And yet, lacking a true reference, teams often compensate by adding ceremony: dashboards, frameworks, governance layers, microservices, coffee machines. All to row harder — without ever checking whether the boat was designed to go straight.
1. Understand the Problem Space First
Before touching technology, define what the system needs to achieve. Every architectural mistake starts when we skip this question.
Take databases, for example. A small startup might thrive on PostgreSQL — fast, simple, and open-source. But when the organization grows, the requirements change: 24/7 uptime, guaranteed SLAs, and vendor-backed support. Suddenly, that “free” choice becomes a hidden liability. You end up paying more for EnterpriseDB than you would have for Oracle — not just in licenses, but in people, because Oracle DBAs are plentiful and EnterpriseDB ones are rare.
The problem wasn’t PostgreSQL. The problem was not defining the need. Was the goal low cost? Vendor independence? Enterprise reliability? Without that clarity, every technology choice is a guess that compounds over time.
Architects should begin not by choosing a stack, but by mapping intent to constraints. If you understand the domain, the right tools and abstractions reveal themselves. If you don’t, the project starts rowing before checking which way the river flows.
2. Evaluate Solutions with Real Cost–Benefit Logic
Once the problem is understood, assess each solution by its value versus complexity. This is where many teams get lost chasing trends — especially around microservices.
Let’s take a small enterprise system with around 40 domain objects. If we assume the effort to design and implement the core business logic as 100 points, moving to microservices adds enormous overhead:
Integration & API design: +50–100 points
Service orchestration & messaging: +20–40 points
Kubernetes and DevOps setup: +30–50 points
Maintenance & versioning: +200–300 points
That’s 400–600 points total — up to six times the original effort — before delivering a single unit of extra business value.
If those microservices aren’t justified by real scaling or isolation needs, it’s pure architectural theatre. The organization ends up spending more on infrastructure than innovation.
☕ The Bridge: The Boat, the Coffee Machine, and the Finish Line
These choices — PostgreSQL over Oracle, microservices over monoliths, Kubernetes over bare metal — are the Dutch boat’s coffee machine moments. They look modern, feel proactive, and photograph beautifully on LinkedIn. But they don’t make the boat float any better.
If we don’t understand why we’re building what we’re building, we’ll always row harder instead of smarter. We keep optimizing the wrong thing — rowing speed — instead of redesigning the boat.
3. The Economics of Understanding
In both software and infrastructure, the real expense isn’t in building — it’s in changing. And change becomes expensive when the structure doesn’t reflect understanding.
Understanding is the only scalable efficiency. Without it, every improvement compounds complexity. With it, simplicity emerges naturally — systems evolve instead of accreting layers of “fixes.”
That’s why architecture isn’t about technology at all. It’s about reasoning: matching what’s needed to what’s built, and doing it consciously. The Japanese boat wins not because it rows harder, but because every oar is in sync — guided by clarity of design.
Summary
The Dutch boat joke reminds us that the finish line isn’t the goal — the journey is. Architectural success isn’t about adopting the trendiest stack or framework. It’s about understanding the problem, modeling it correctly, and only then choosing the simplest technology that fits.
When we understand before we build, we design boats that float — not just ships that look good on the dock.
