Many organisations encourage a technical mindset focused on getting features working as quickly as possible however if you want a good design you must take a more strategic approach where you invest time to produce clean designs and fix problems. During this part, we will discuss why the strategic approach produces better designs and is actually cheaper than the tactical approach over the long run.
POSD - tactical programming
most programmers approach software development with a mindset I call tactical programming in this approach your main focus is to get something working such as a new feature or a bug fix. at first glance, this seems totally reasonable what could be more important than writing code that works?
tactical programming makes it nearly impossible to produce a good system design as the problem with tactical programming is that it is shortly sighted, if you are programming tactically you are trying to finish a task as quickly as possible as a result planning for the future is not a priority you don’t spend much time looking for the best design; you just want to get something working soon. you tell yourself that it’s okay to add a bit of POSD - complexity in software design or introduce a small kludge or two, that allows the current task to be completed more quickly, this is how systems become complicated as we discussed complexity is incremental the accumulations of dozens or hundreds of small things if you programming tactically each programming task will contribute a few of these complexities each of them probably seems like a reasonable compromise in order to finish the current task quickly. before long some of the complexities will start causing problems, and you will begin to wish that you didn’t take those shortcuts but you will tell yourself that it’s more important to get the next feature working than to go back and refactor existing code. refactoring will definitely slow down the current task so you look for quick patches to work around any problems you encounter this just creates more complexity. pretty soon the code is a mess, but by this point, things are so bad that it would take months of work to clean up.
almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado.
Link to originaltactical tornado
the tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion, when it comes to implementing a quick feature nobody gets it done faster than the tactical tornado. in some organizations, management treats tactical tornados as heroes. However, they leave behind a wake of destruction. they are rarely considered heroes by the engineers who must work on their code in the future. typically other engineers must clean up the messes left behind by the tactical tornado which makes it appear that those engineers who are the real heroes are making slower progress than the tactical tornado.
Link to original
POSD - strategic programming
the first step towards becoming a good software designer is to realize that working code isn’t enough it’s not acceptable to introduce unnecessary complexities in order to finish your current task faster. the most important thing is the long-term structure of the system. most of the code in any system is written by extending the existing code base, so your most important job as a developer is to facilitate those future extensions. thus you should not think of working code as your primary goal, though of course, your code must work your primary goal must be to produce a great design. which also happens to work this is strategic programming.
strategic programming investment types
- some of the investments will be proactive. for example, it is 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 try a couple of alternative designs and pick the cleanest one.
- other investments will be reactive. No matter how much you invest upfront there will inevitably be mistakes in your design decisions. overtime these mistakes will become obvious. when you discover a design problem don’t just ignore it or patch around it; take a little extra time to fix it. if you program strategically you will continually make small improvements to the system design. this is the opposite of tactical programming. where you are continually adding small bits of complexity that cause problems in the future.
how much to invest?
Link to original
- what is the right amount of investment? A huge up-front investment such as trying to design the entire system won’t be effective. this is the waterfall method, and we know it doesn’t work. the ideal design tends to emerge in bits and pieces, as you get to experience the system thus, the best approach is to make lots of small investments on a continual basis. I suggest spending about 10-20% of your total development time on investments this amount is small enough that it won’t impact your schedules significantly but large enough to produce significant benefits over time.
- your initial project will thus take 10-20% longer than it would in a purely tactical approach. that extra time will result in a better software design and you will start experiencing the benefits within a few months. it won’t be long before you are developing at least 10-20% faster than you would if you had programmed tactically. At this point your investments become free. the benefits from your past investments will save enough time to cover the cost of future investments you will quickly recover the cost of the initial investment.