Why Look at Toyota?

Toyota has long been the benchmark for lean, high-quality production. Their philosophy—the Toyota Way—emphasizes continuous improvement, respect for people, and designing processes for stability and efficiency. The results are legendary: fewer defects, lower costs, higher morale.

In software, we face a similar challenge: delivering complex systems under pressure, where quality is hard to see and easy to postpone. Borrowing from Toyota makes sense—but software is not steel or cars. Our domain is more fluid, faster, and cheaper to change. That difference is key.

Physical vs Digital Domains

In car manufacturing, each step is physical, slow, and expensive. A mistake at the design stage ripples through the entire line. To cope, Toyota built systems where defects are visible and corrected early, with workers empowered to stop the line. The philosophy is: design right, then improve relentlessly.

Software is different. Changing a line of code is almost free. Rebuilding an entire system overnight is possible. But paradoxically, this freedom has led teams to neglect design altogether. Success is measured at the finish line—does it run, do tests pass, does Sonar report green—rather than whether the “boat” itself is well designed to keep working.

Here is where object-oriented (OO) design comes in. OO makes the boat—the domain model—explicit. It creates a shared mental model of how the system works, allowing teams to learn and adapt without losing coherence.

The Boat Joke, Revisited

Recall the classic boat joke: the Japanese boat, lean with eight rowers and one coxswain, glides to victory. The other team adds managers, consultants, gadgets, and processes—complicating without improving.

In software, it’s worse: we don’t even compare boats. There is only one race, and as long as the boat reaches the finish, we assume success. Reviews, tests, and metrics measure outcomes, not whether the design itself is efficient.

The lesson of the joke: stop focusing solely on the finish. True quality isn’t “does it work?” but “how cheaply and efficiently can we get there?” Only OO makes this boat—the design—visible.

Why Learning Stalls

If teams only row in boats where “reaching the finish” is all that matters, their learning is constrained. They master the process—unit tests, MR templates, Sonar checks—but never gain intuition about design. Metrics reward coping, not improving. Inefficiency compounds, and future work gets harder.

In contrast, OO teams learn about the domain itself. Each class, relation, and abstraction forces a conversation about what the system is, not just what it does. Over time, this shared model becomes the real source of speed and quality.

Small Teams, Big Systems

OO thrives in small, focused teams. Three to four developers are often enough to maintain systems with hundreds of domain objects. The key is a shared vision of the model.

Large teams struggle. With too many voices, the common mental model fragments, and code degenerates into procedures glued together by tests. Ironically, this makes large projects slower and less stable, not more.

This mirrors Toyota again: lean teams on the factory floor are empowered to own quality. Scale comes not from more hands but from clarity, design, and flow.

Respect for People, Respect for the Domain

Toyota’s “respect for people” is often misunderstood as a soft value. In practice, it means: empower people to own problems, stop the line, and improve design.

OO embodies the same. Developers are not test writers or template fillers; they are domain modellers. They create clarity, prevent waste, and make future work cheaper. This is not extra—it is the essence of professional software engineering.

Procedural or functional approaches may seem easier in the short term, especially for stable, well-bounded problems. But when the domain evolves—and most business domains do—these approaches lack a shared model. The result is brittle systems, rising costs, and frustrated teams.

Implications for Scrum

Scrum often inherits Toyota terms—sprints, retrospectives, velocity—but risks losing the spirit. When tasks are chopped into tickets and quality is measured by throughput, the “finish line” mentality returns.

A Toyota-inspired Scrum would look different:

Domain focus. Backlog items are framed in terms of the model, not just features.

Small, empowered teams. No more than 3–4 developers share responsibility for a coherent model.

Stop-the-line moments. Bugs or unclear designs pause the sprint, because design debt compounds faster than feature debt.

Learning over velocity. Metrics track how the model improves, not just how many tickets close.

This shift is subtle but profound: from rowing harder to building better boats.

The Real Point

OO is not about nostalgia or style—it is Toyota thinking adapted to software. Continuous improvement, respect for people, and design-first discipline translate directly into building systems that last.

The joke about boats teaches us: quality is not just finishing the race but how efficiently we get there. In manufacturing, this truth built an empire. In software, it remains underused.

The way forward is clear: stop measuring only outcomes, start designing the boat. Object-oriented modeling is how we make design explicit, learning possible, and quality sustainable.