Strategic vs Tactical Programming and which is better
Diving deep into these programming mindsets, and implementing them into the software development process
Recently while reading A Philosophy of Software Design by John Ousterhout I came across the ideas of Strategic and Tactical programming. Both of them can be described as a state of mind while approaching and writing code.
100% credit for the ideas described in this post goes to John Ousterhout and his book, but I just wanted to share my thoughts and elaborate on his ideas. I think this could really help a lot of people, especially those starting out their careers in software engineering.
The tactical mindset is focused on speed of development while the strategic approach is more time consuming but produces better results in the long term, and may even end up costing lesser than the tactical approach. Let’s look at each one in detail.
Tactical Programming
Are you focused on building a feature that needs to go into production by next month? Are your working on critical bugs that need to be solved asap? Or maybe you are working on optimising or automating certain tasks that could save your company time and money.
When doing any of the above your main focus is to get it done and make sure that it satisfies all the user stories, and passes all test cases. You do not want to be the one creating blockers for other team members or slowing them down.
This is tactical programming, and this is how a majority of us operate daily.
Nothing wrong with it. This kind of mindset works and has been providing results for a long time now. But the problem here is that our goals are time bound. We are racing to finish tasks as quickly as possible, leaving no room to think about the big picture.
Little thought is given to design patterns, the overall structure of the code or the impact of the current implementation could have in the future especially when someone else tries to make an improvement.
A variable not named properly, hard coding some value or calling another function from a module seems okay. It sure adds a little bit of complexity, but you can always add a comment explaining why you did something a certain way. Most importantly your code seems to work, so no big deal.
But everyone is thinking the same way. Everyone is adding a little bit of complexity to the code base. And before you know, you start having problems and inconsistencies.
Complexity compounds.
But by the time the problems start surfacing, you have already moved on and are busy working on the next feature. So again to fix the current problem, you choose a shortcut. You just want to make it work and close the bug. Well this again seems small in the short term, but it compounds over time.
You can see how this slowly leads to a vicious cycle and can be very difficult to change.
In the book, the author also describes a developer whom he calls the tactical tornado. This is the fastest person on the team, who just seems to be able to constantly pump out code. But they leave behind them a wake of destruction, which other engineers might have to clean up in the future.
Now that you have an idea about the tactical style of programming, let’s explore the strategic style.
Strategic Programming
In contrast to tactical programming, the main goal of strategic programming is not to write code that works as soon as possible. In strategic programming, the focus is more towards the long term structure of the system and to facilitate future enhancements.
This way of programming is more design oriented. The idea is to produce sustainable code, even if it takes more time. This could mean proactively thinking about all the edge cases that could happen, naming variables more clearly, creating more abstractions, following the DRY principle, adding pure functions, writing extensive test cases and documentation, following type rules, following consistent design patterns, thinking about alternative solutions etc…
This takes more effort, more time and definitely you will uncover other issues that could be related or unrelated to your task at hand. So strategic programming requires an investment mindset. This extra effort that you put in the short term will pay off in the long term.
Proactively looking for code smells and fixing the issues instead of patching around them, compounds over time, just like how bad decisions also compound. All of these will lead to more robust and well designed systems ready to be extended or scaled with a code base that makes the experience of programming much more enjoyable for future developers.
It is much easier to start a new project and pump out code, than reading through code and performing maintenance. Strategic way of programming can also help in reducing the cognitive effort required in reading and understanding code. Good code should explain itself.
So always program with a strategic mindset ?
No.
Strategic programming could be a productivity killer for some people, almost similar to procrastination — you spend the majority of time trying to find the perfect design or structure, and end up getting very less done. Nothing can ever be perfect. Plus, companies put people on a deadline because they need to get it done, and may even encourage the tactical style.
If you always program tactically, you might be around 20% faster in finishing your work, but overtime your development speed will slow down because of bad design and all the complexity introduced.
If you always program strategically, you won’t be able to get anything done on time. In environments where speed is critical like startups, this is definitely not an option.
The key here is to find a balance, which is not easy. The idea is to follow both the tactical and strategic mindset while programming and apply them in a way that improves overall productivity as well as ensures a good design — the best of both worlds.
The author of the book suggests dividing our time between both mindsets.
Best of both worlds
The 80–20 rule can be applied to this — 80% tactical programming, 20% strategic programming.
So now even if you are say 20% slower than you were before doing strategic programming, in the long run everything compounds, and you will quickly gain back all the time initially spent. Doing tactical programming all the time would lead to issues compounding which would finally result in more development time and cost for the company.
Spending 20% of time on strategic programming combined with good prioritisation skills could lead to noticeable results in a span of a few months. Spend the strategic time on more critical things, that have a higher chance of being extended or will need optimisation in the future.
Facebook is an example of a company that encouraged tactical programming. Their motto was “Move fast and break things”. This helped Facebook scale rapidly and push features faster than their competitors. But over time, their code base suffered, to the point where fixing bugs created previously was slowing down their current development.
So Facebook updated their motto to “Move fast with stable infrastructure”, thus encouraging their engineers to focus more on good design principles and build a stable foundation.
Because when you build something that you don’t have to fix 10 times, you can move forward on top of what you’ve built — Mark Zuckerberg
I am guilty of tactical programming, and I have been doing it till the day I came across this idea. My focus was to just get things done. The amount of time I spent thinking about the bigger picture and overall structure of the system was minuscule when compared to the time spent doing tactical programming.
But I have come to realise the need to trust in the laws of compounding and the initial effort put into strategic programming will eventually pay itself off. At the same time, not getting carried away in strategic programming is critical.
I think the idea of tactical and strategic programming can be considered as a tool for software engineers, which they can apply as and when required. Ultimately the goal is to solve problems and create value for the company. These ideas simply help optimize doing that.
If you are a software engineer interested in software architecture and design I would highly recommend reading A Philosophy of Software Design by John Ousterhout.
Feel free to leave any comments or suggestions or send them by email at hello@adarshmenon.in. Connect with me on Twitter, LinkedIn and check out my YouTube Channel.
