I've recently splurged on some software development books and came across an interesting concept in A Philosophy of Software Design by John Ousterhout. Have a read and consider which approach you and your team members practice.
What is Tactical Programming?
As a developer one of your primary goals is to implement and release working code. The Tactical developer works fast and can oftentimes produce more features/bug fixes than their Strategic counterparts. However, the Tactical developer encounters issues within the codebase and takes the short-sighted view to patch over the issues instead of addressing them. In this approach, issues aren't resolved or refactored and instead additional complexity is introduced by extending poorly designed code to introduce their code. We call this complexity: technical debt. They then kick the can down the road when it comes to refactoring 'the big ball of mud' that the codebase has become.
What is Strategic Programming?
The tenet that 'working code is not enough' sufficiently distinguishes Strategic developers' approach from the Tactical developer. Here, the goal is a great design. Taking a long term view of the codebase considers how to introduce the change whilst also resolving issues along the way. You can think of a Strategic developer as a Steward of your codebase, ensuring the long term health of the code and thereby reducing complexity and technical debt where possible. This might be through proactive investment such as planning the design and weighing up the options before beginning implementation. Alternatively, this could be the result of reactive investment by refactoring an issue encountered during a change.
Contrasting Strategic and Tactical approaches
Tactical programming is faster in the short term and has a time and place for instance, producing a proof of concept to validate a concept. However, the shortcuts taken to produce software using this approach will eventually work against yourself and your team resulting in incremental degradations in productivity.
Strategic programming will prove to be slower initially. This can be down to proactive planning prior to implementation of a feature or due to the improvement of poor design encountered whilst attempting to introduce a feature. Yet, it is these investments of time that will add up over the course of time to benefit developer productivity and gradually reduce technical debt.
Tactical programming in the Wild
John Ousterhout coined the term 'Tactical Tornado' for the individual that takes tactical programming to the extreme. This takes the old Facebook motto, 'Move fast and break things' to its limit. Even Facebook realised, with time that this motto was not serving their best interests as the quality of their codebases degraded. The motto then changed to 'Move fast with stable infrastructure', then simply 'Move fast' and now 'Move fast together'. Tactical Tornadoes might be praised by management for their high output, but those that work alongside them will oftentimes have to pick up the slack by addressing their poorly designed code. This, then makes the team members look slow in contrast and exacerbates the relationships within the team and management.
My experience
I have experienced both approaches whilst working as a developer. Occasionally, the needs of the business pressure folks to prioritise speed, this is especially true within Startups, unfortunately leading to new technical debt. A good code/peer review process will push back against some changes with a preference for a more strategic approach e.g: Why is it designed like this? Can we try such and such approach instead please.
Conclusion
After reading this, I hope you gained some value. I have been guilty of programming tactically in the past and appreciated the examples within the book. I would love to hear how you mitigate tactical programming within your place of work. My personal favourite is a great peer review process however, sharing this concept with my team could reduce complexity and tactical programming prior to it reaching the peer review stage.
Top comments (0)