The Intertwinement of Science and Engineering in Software Development - Part 2: Discovering the Japanese Boat
I specialize in developing object-oriented java applications that aligns with business objectives, using Domain-Driven Design principles to ensure technical decisions drive tangible value. By focussing on a deep understanding of the business domain, I craft solutions that solve real problems while maximizing ROI. My approach evaluates the cost/profit ratio of every decision—only implementing technologies when the benefits outweigh the costs. I’ve been called in to revive stalled projects and address challenges where others have struggled. My focus is on creating software that not only meets but exceeds business expectations. Whether working with legacy systems or modern frameworks, I select the right technologies to maximize value—not just follow trends. I believe software should be a strategic asset, and this mindset guides every decision I make in development.
In Part 1, I introduced development speed (valuable features delivered per developer per time unit) as the heartbeat of software quality, signaling issues like technical debt when it slows. This speed relies on two intertwined forces: A, understanding the business domain (the “what”) through a scientific approach, and B, implementing it simply (the “how”) with clear, readable code. Both are essential to row like the Japanese team—lean and synchronized—not the bloated Dutch boat. Today, let’s explore this intertwinement of science and engineering, and how their continuous cycle drives sustainable speed.
The science—A—is crafting a rich domain model, like a scientist analyzing a complex system. It’s about identifying actors (e.g., customers, orders), their interactions, and rules through collaboration with domain experts. Spending time with an expert, asking targeted questions, can map out a model that captures the business’s essence. This isn’t guesswork; it’s hypothesis, testing, and refinement, ensuring the software mirrors the business reality of the domain.
The engineering—B—is implementing that model as simply as possible. Think “Mickey Mouse” code: clear, functional, and mapped 1:1 to the domain (e.g., an Order class with applyDiscount()). Avoid unnecessary frameworks or layers that add drag, like the Dutch team’s extra managers. Object-oriented (OO) programming shines here, as it aligns code with the domain model, making discrepancies obvious.
The magic lies in their cycle. A clear domain model (A) enables simpler implementation (B), while coding tests the model’s correctness as it will reveale gaps and spot design flaws. These short, frequent feedback loops refine the model, boosting speed and quality. Procedural coding, by separating data and logic, often misses this cycle, leading to misaligned solutions. Only by mastering both disciplines, both the science and the engineering, can you achieve the Japanese team’s efficiency.
In small applications, say 3 to 4 entities, the gain in an Object-Oriented approach is still there, but not large. But as systems grow, an Object-Oriented approach becomes the difference between a sustainable product and a 5-yearly rebuild cycle. The often sought solution of microservices only makes the feedback loops even longer to the point where one can't even tell anymore where the problem is.
Software engineering is about discovery and efficiency, not about knowing version X of framework Y.
In the next part I'll dive deeper into the engineering side of software development.
