Tactical vs Strategic Developers

"A Philosophy of Software Design" pt.1

In the world of software creation, developers have different ways of thinking and working. In his enlightening book "A Philosophy of Software Design," John Ousterhout talks about the ideas and methods that make software design work well (or at least better). One important thing he discusses is the difference between tactical and strategic developers. This helps us understand the various approaches these developers use when creating software, and why the modern approaches that companies adopt bring to a dangerous path.

The Divide

Tactical Developers

Tactical developers are often focused on the immediate tasks at hand. They are adept at solving specific problems quickly and efficiently (often in terms of their time). These developers excels or just focus in coding and implementing features, demonstrating proficiency in the tactical aspects of software development. Their skills lie in writing code, fixing bugs, and ensuring that the software functions as intended at a first glance.

However, the drawback of a purely tactical approach is the potential for shortsightedness. Tactical developers may prioritize quick fixes over long-term sustainability, leading to a codebase that becomes increasingly complex and difficult to maintain over time.

Strategic Developers

On the other hand, strategic developers take a more holistic view of software design. They are concerned not only with the current problem but also with how their solutions fit into the broader context of the entire system. Strategic developers focus on creating a maintainable, scalable, and adaptable architecture.

Ousterhout emphasizes the importance of strategic thinking in software design. Strategic developers invest time in designing abstractions, creating modular and reusable components, and considering the long-term implications of their decisions. While this approach may take more time upfront, it pays off in terms of the system's ability to evolve and adapt to changing requirements.

The flaws of the “modern approach”

In the evolution of modern software development practices, the emphasis on metrics such as velocity, inspired by frameworks like DORA, has been both a bless and a pitfall for companies.

While the intention behind adopting these metrics is often to streamline processes, reduce friction, and enhance overall efficiency, a common trap arises when organizations prioritize numerical outcomes over the qualitative experiences of their engineering teams.

In an environment driven by a relentless pursuit of faster pull request production and higher velocity, there is a risk of inadvertently fostering a culture that incentivizes individualistic behaviors and shortcuts. This can result in a focus on meeting numerical targets at the expense of thoughtful and sustainable software development practices. Striking a balance between quantitative metrics and a qualitative understanding of engineers' experiences is crucial to nurturing a healthy and sustainable software development culture. Companies should recognize the importance of creating an environment that values collaboration, innovation, and the long-term well-being of their development teams, rather than solely fixating on numerical indicators.

This focus on fast feature delivery and hitting numerical targets (un)intentionally allows a build-up of unavoidable (and accepted) technical debt, shortcutting on hasty decisions making the codebase harder to maintain.

Instead of addressing the root problem, some companies accept this as a normal part of the process. They try to manage the consequences without realizing that their development principles might be flawed. A classical example of this is Facebook/Meta, which shifted from "Move fast and break things" to "Move fast with stable infrastructure" recognizing at some point that their initial approach, while promoting innovation, was increasingly causing problems and accumulating technical debt brought to unmaintainable and unstable systems.

To break this cycle, probably companies need to rethink their fundamental principles and create a more sustainable and resilient software development culture, accepting that engineers are not working in an assembly line and that software creation is still art and craft.

In conclusion

Optimizing investment in software design is crucial for long-term success. Emphasizing the drawbacks of a large upfront investment (think about the old waterfall method), the suggestion of Ousterhout is to favor a continuous, smaller investment approach, dedicating approximately 10'-20% of total development time. While this may slightly extend project timelines initially, the resulting enhancements in software design become evident within a few months, ultimately accelerating development speed as a consequence and not as a requirement.
Investing in good design is a continual effort that pays off in the long run. Small, consistent investments prevent minor issues from snowballing into major problems. It's essential to adopt a strategic approach consistently and view investment as a present-day necessity, not a future task. Postponing cleanups during a crunch is tempting but risky, as it often leads to a perpetual cycle of delays and a shift toward tactical approaches. The longer design problems linger, the more challenging they become to address.