Strategic vs. Tactical Programming
2026-03-09 00:02
Status: #child
Tags: #books #software #philosophy #design
Strategic vs. Tactical Programming
Most projects follow tactical mindsets when it comes to writing software. That means one must focus on getting features working as quickly as possible. However if you want a good design then we must be more strategic and invest time to produce clean designs and fix problems.
Tactical Programming
If everyone follows the mindset of "I need to finish this task and/or fix this bug as quickly as possible" then we will fall in the loop outlined in Causes of Complexity. Everyone programs tactically and we will shortly accumulate a system ending collection of assumptions and bad design decisions. This type of legacy will mean that only fewer and fewer people will understand the system as a whole in the future.
Not only that, by the time one notices this nastiness, the cost of going back to fix/refactor it will be pretty large. Programmers will convince themselves that it's better to go and implement a new feature (you guessed it.. tactically) instead of refactoring the old source code that has accumulated tactically influenced decisions.
At almost any software organization, there exists someone who takes the tactical paradigm to an extreme. This is known as the tactical tornado; a person who pumps out code far faster than others but works in a totally tactical fashion. When it comes to hard deadlines, these guys are a gem. However, these guys leave behind some very radioactive blocks of logic.
The engineers who fix the issues created by the tornados (i.e., cleanup after them) are often seen as the slow ones by poor management even though those are the real heros :)
Strategic Programming
The first step towards becoming a good software engineer is to realize that "working" code is not sufficient. It should not be acceptable to produce complexity in order to finish your task faster as the most important thing in the long term is the structure of the system.
Strategic programming is a sort of an investment mindset. One invests time today to make it easier for those who come after.
Some investments might be proactive: it's worth taking a little extra time to find a simple design for each new class rather than implementing the first idea that comes to mind. Other investments are reactive: when discovering a design problem, we should not just ignore it or patch around it; we shall take a little extra time to fix it.
A huge investment, such as trying to design the entire system, won't be effective. The ideal design emerges in bits and pieces as one gets more experience with the syste. Therefore, one should make small investments on a continual basis. Perhaps spending 10-20% of development time on investments. There will be a breakeven point where you will not even see the 10-20 percent of time cost because the benefit of past investments will cover the cost of future investments.
Note that the term technical debt is often used to describe the mess left by tactical programmers; it's a description of borrowing time from the future to finish a current task faster which is often not a good decision. And unlike financial debt, most technical debt will be left unpaid.. one keeps paying for it forever :(
References
Clair Obscur: Expedition 33 :)
Causes of Complexity
Symptoms of Complexity