When you develop software, you have two attitudes to choose from. You either develop in a quick and dirty way or in an orderly, planned, and future-oriented way. Both of these types of development have their advantages and disadvantages.
Tactical Development
Tactical development is characterized by the high initial speed at which you begin to develop and create the functionality of your software. With this attitude, your main goal is to have code that works. With this way of working, you don't spend much time looking for the best design of your program but instead focus solely on finishing as quickly as possible. Your sight is short term. It doesn't matter if you are adding complexity to the program, as long as you are getting the task done as quickly as possible.
This type of development is encouraged by businesses that want their code or program to be out as quickly as possible, regardless of the cost. Mostly deployed by software agencies juggling dozens of projects at the same time. When you want to build a product very very quickly and you are aware that it will be disposable, you will fall into this hole.
Tactical Development produces programs that over time become more and more difficult to maintain, to the point that it is so impractical that it seems easier to do scrap it and do it again to continue. This way, the speed of development skyrockets at the start but slows down to a halt as time goes by.
Once you start programming a project this way, it is very hard to change. And unfortunately, you will not believe it but most organizations and programmers prefer this method.
Here are some hints that you are coding tactically:
- Hard-coding of parameters that should be configurable
- Unnecessary duplication
- Lots of unused files and functions
- Poor or extremely complicated abstractions
- Bad code readability
- Not adding exception handling
But what's the big deal? You had to deliver a fix quickly and hard-coded a value, and it added a bit of complexity. But that's the mindset of everyone in your team and slowly your codebase starts stinking and having problems.
When you start thinking short-term, and you just want to fix that bug so you can handle other things, that's tactical programming. Now that you have an idea of this style of coding, let's explore the strategic style.
Strategic Development
This type of development is characterized by paying attention to the design and quality of the code. The most important thing is to not directly finishing the pending task, but also to do it in a way that facilitates future tasks and keeps complexity under control.
Code that works is not enough. While working, instead of introducing parts that make the code more complex, you keep looking out for ways to improve even a small part of it.
You need to approach your coding with an investment attitude. The more time you invest in improving your code design, the better return you will get later on. This kind of attitude will slow you down at first, but over time you will pick up speed when developing new features and maintenance will become a piece of cake.
Here are some of the strategic development practices:
- Testing multiple implementations to find the cleanest one
- Documenting and commenting in your code
- Cleaning and improving your code whenever possible
- Thinking of all the edge cases
- Naming variables more clearly
- Following design patterns
- Writing test cases
Conclusion
As you can see, strategic development takes longer to deliver results, but it is worth it if it is a major project with along expected lifetime.
The motto at Facebook used to be "Move fast, and break things". They encouraged tactical programming and it helped them rapidly scale up and push features at lightning speed. But their code base suffered and fixing bugs was taking more time than developing new features. They were criticized for this motto to the point that they changed it to "Move fast with stable infrastructure".
Think of it as building a house versus a hut. Which one do you think will last longer? Sure, the hut will be faster to put up but neither will it last long nor will it let us build a second story on it if we want to scale it. But at the same time, you wouldn't want to construct a whole house if you are just planning on camping for a night. Both of these mindsets are just tools for the developers to use in different situations, choose whichever is appropriate.
This article was inspired by and based on the book "A Philosophy of Software Design" by John Ousterhout.