Coping vs. Improving in Software Engineering - Part 3: The Path to the Japanese Boat

In Parts 1 and 2, I argued that development speed—valuable features delivered per developer per time unit—is the heartbeat of quality, driven by the intertwinement of science (A: domain understanding) and engineering (B: simple implementation). Their continuous cycle ensures sustainable speed, like the Japanese rowing team’s efficiency. But what happens when teams skip this cycle? They cope instead of improve, turning into the bloated Dutch boat. Today, let’s explore coping vs. improving, and why an object-oriented (OO) mindset is the road to success.

Coping; staying afloat but slowing down

Coping arises when domain understanding is shallow. Without a rich model (A), complexity multiplies: features misalign, code tangles, and knowledge gaps grow. Instead of addressing the root, teams reach for band-aids:

Tools-as-crutches: SonarQube to highlight “smells,” or excessive unit tests for “safety.”

Architectural band-aids: piling on frameworks or fragmenting into microservices to “decouple.”

These measures promise fixes but only mask symptoms. They lengthen feedback loops, obscure the real issues, and slow the pace. Microservices, for example, split the domain across network calls, making it nearly impossible to pinpoint where problems originate. Coping is reactive: patching leaks instead of building a watertight hull—leading to inevitable rebuilds every few years.

Improving; rowing like the Japanese team

Improving means embracing the cycle of science and engineering. Start with science (A): model the domain deeply, through dialogue with domain experts. Then engineer (B): implement that model in the simplest way possible.

OO here is not just a programming style, but it’s engineering discipline. It’s aligning code with the domain so that every object encapsulates real business behavior (e.g., an Order class applying discounts). By iterating quickly between modelling and implementation, gaps surface early: missing rules, misunderstood interactions, hidden complexity. These tight loops refine the model and keep the system aligned with the reality of the business domain.

Unlike procedural or purely functional approaches, which separate data and logic, OO keeps them together, making the domain transparent. And because the model is readable beyond the code, domain experts themselves can review and refine it so the total thinking power to develop an application is significantly larger. Efficiency and lifespan are no longer dependent on static analysis or test counts, but on continuous collaboration and feedback.

Why it matters in the long run

Over 10 meters, the Dutch and Japanese boats might finish close. But over 1000 meters, the Japanese efficiency becomes decisive. Likewise, in small systems, coping and improving may look similar. As systems grow, the difference compounds: OO scales by understanding and streamlining, while coping adds layers and drag. In a well designed OO application, having 20 entities or having 200 entities does not affect the maintainability of the application much, but in a non-OO approach you would be dead in the water.

Software engineering is not about mastering framework versions or tool dashboards. It’s about mastering the domain, keeping code minimal, and letting science and engineering reinforce each other.

Coping might keep you afloat, but only improving builds a Japanese boat.

'Monolith’ is often used as a derogatory term, but a well designed monolith can stand the test of time. Stonehenge is still standing strong after thousands of years but no one has ever heard of the ‘Microservices of Stonehenge'.