A few months ago, I read A Philosophy of Software Design by John Ousterhout and found its discussion of tactical and strategic programming quite insightful.1
Tactical programming
The book talks about tactical programming as a short-sighted approach to developing software. The focus is on shipping many features and fixes as fast as possible without any planning for the long-term design of the software. To put it simply:
Just get something working.
The disregard for future planning results into a highly complex codebase filled with technical debt; as shortcuts, band-aid solutions, and bad practices often become the norm in tactical programming. Sure, tactical programming is fast in delivering many features at first but it’ll slow you down dramatically later.
Even more so, complexity and technical debt can accumulate to a point of no return. This can bring developer productivity to a complete halt, which can threaten the life of a project… Oh no!
Strategic programming
On the bright side, the book presents strategic programming as a type of long-term thinking and investment mindset approach to software development, wherein:
Working code isn’t enough.
Every organization aspires to achieve a great design in the software they develop. It’s an important goal to maintain competitiveness and business excellence.
The focus of strategic programming is producing a great and working design that facilitates a long-term, maintainable, and extensible structure of the software. Craftmanship is the heart of strategic programming and I find this to be the ideal!
However, strategic programming requires time to be invested upfront. This is used in planning and experimenting on how to attain a robust software design. As a result, strategic programming slows you down at first but it’ll speed you up dramatically later. This short-term drawback must be understood and communicated as it’s important to maintain commitment to the strategic approach before we’re able to see the ROI.
Design stamina hypothesis
The topic of strategic and tactical programming coincides with Martin Fowler’s discussion about the Design Stamina Hypothesis.2
The image below shows a simplified version of it:
Tactical programming can deliver a lot of features rapidly at the onset, but its disregard for design slows down its productivity later on. Strategic programming isn’t able to deliver a lot features early on, but it’s eventually able to outpace the productivity from tactical programming as the time spent in investing on a good design pays off tremendously.
Closing thoughts
Writing automated tests is one of the effective ways in achieving a great software design as it forces a developer to think about the testability (which implies modularity) of the code he/she writes. These tests take time to write and it’s incredibly valuable to write them.
The value of investing in a comprehensive and automated test suite isn’t often realized by all organizations. To those organizations that do, they have an edge.
To name a few advantages: these organizations are much more confident about the system working correctly, thanks to the numerous automated checks in their arsenal. They can refactor their codebase and improve their designs fearlessly. They can keep implementing features and move forward while worrying significantly less about regressions.
It’s truly rewarding when one realizes that working code isn’t enough :)
Footnotes
-
Discussed in chapter 3, pp. 13 to 18 ↩