Overcoming Resistance – Part 4: Recognizing the Japanese Boat in a Dutch World

In the previous parts of this series, we've explored development speed as the ultimate measure of software quality: the amount of valuable features delivered per developer per time unit, sustained or improved over time. We've seen how this speed is driven by the intertwinement of science (A: deep domain understanding via rich modeling) and engineering (B: simple, object-oriented implementation). Their continuous cycle turns potential chaos into lean efficiency, like the Japanese rowing team gliding to victory. But as we've discussed coping vs. improving approaches, a bigger question emerges: If your entire professional life has been spent in Dutch boat solutions, bloated with tools, frameworks, and reactive fixes—would you even recognize a Japanese boat if it passed by, or if someone explained it to you? In this part, we'll analyze the barriers to adopting improving methods, including how change agents are often viewed as antagonists. We'll also dive into why object-oriented (OO) thinking, with its focus on the "what" over the "how," is key to breaking through these barriers.

The blind spot starts with priorities. Object-oriented development begins with the what: what business actors (domain objects) exist, what lifecycles they follow, how they interact. Implementation flows naturally from this model and stays aligned with it. Procedural and functional approaches invert this order: they start with the how—functions, transformations, streams—while leaving the domain implicit and fragmented. The difference seems small in a system with three entities. But at scale, OO compounds clarity while procedural code compounds steps. Over 1000 meters, the Japanese boat pulls away. OO continuously reinforces the A → B feedback cycle: science feeding engineering, engineering feeding back into science. Procedural and functional development break this loop—implementation becomes execution, not exploration—so the learning gained during building is minimal.

The blind spot for the 'what' is reinforced by lifelong Dutch boat habits. Many developers and teams have spent years mastering coping strategies: layering microservices to “decouple” tangled code, enforcing 90%+ unit test coverage for a false sense of security, or relying on code metrics to flag syntax issues after the fact. These tactics feel like progress because they address immediate pain points, but they perpetuate inefficiency. Logically, if your frame of reference is only reactive tools, a proactive, domain-first approach—like building a rich domain model and implementing it as simple as possible in OO—might seem alien or overly simplistic. “Why model the domain when we can just add another service?” the thinking goes. This confirmation bias dismisses improving methods as theoretical or unnecessary, even when explained clearly. The result? Organizations stuck in rebuild cycles, celebrating small wins (like a slightly faster sprint) while ignoring the drag of their bloated setup.

This resistance is amplified by EINO's - Engineers in Name Only. Professionals who excel at syntax, tools, and frameworks but lack a results-oriented mindset. Drawing from Fiedler's Least Preferred Coworker (LPC) test, which distinguishes task-focused from relationship-focused leaders, many in IT fall into a narrow task-orientation: low LPC in code mechanics (e.g., knowing Spring Boot v3 inside out) but not in delivering business value. These EINO's prioritize tool proficiency because it's measurable and certifiable—badges for AWS or Kubernetes—but true engineering requires conceptual modeling, logic, and simplification. More developers can handle procedural or functional programming (straightforward transformations or streams) than can craft effective OO models, which demand abstracting the domain into cohesive entities. This scarcity creates a culture where coping is the norm: “We’ll fix it with more tests or services.” Shifting to Japanese efficiency threatens this comfort zone, as it requires unlearning tool reliance and embracing domain mastery.

Resistance manifests in two key ways. First, misunderstanding: coping mindsets frame Japanese solutions as “too idealistic” or “not scalable,” missing how OO's focus on the what (domain essence) bypasses entrenched hows (legacy processes). For example, domain experts often describe “how they've always done it,” but OO modeling escapes this by conceptualizing the core problem—building what the business needs, not what it wants. This naturally uncovers efficiencies, like adapting an Order object's lifecycle (pending to shipped) without rewriting scattered functions. Second, perceiving change-bringers as antagonists: advocates for domain-first OO are often seen as “badgering” critics, disrupting egos or job security. In toxic teams, this leads to passive dismissal, perpetuating Dutch bloat and eroding development speed.

Yet, the rewards of overcoming this are immense. A domain model isn't just code—it's a verbose, readable representation of logic and interactions, accessible to anyone knowing the business. Domain experts can read, understand, and refine it, democratizing the core setup beyond developers. Efficiency and lifespan aren't measured by behavior tests or syntax checks (which can't gauge long-term viability); they're enhanced through the model's feedback loops with implementation. As apps grow, OO's edge sharpens: mutable objects traverse lifecycles cohesively, adapting to new rules (e.g., adding “refunded”) in one place, revealing emergent uses from deeper understanding. Functional/procedural snapshots spread logic, making adaptations harder—coping by duplication, not improving through insight.

Organizations can break the cycle with pilots that demonstrate sustained speed via domain modeling and OO, framing it as empowerment, not criticism. Train for conceptual thinking—solid logic minds capable of abstracting domains—rather than tool certifications. The shift from coping to improving isn’t easy, but it transforms antagonists into allies, turning Dutch boats into Japanese fleets.