The OODA loop is a well known concept that originates from military strategy, but that also has applications for other areas, such as business and sport. A simple summation is that a single iteration of this loop involves analysing a situation, deciding on an action and then taking that action. In simple scenarios (one on one dogfights) it is vital that you can iterate faster than your opponent in order to beat them. Once you get inside your opponents OODA loop, your behavior begins to seem unpredictable to them and they are unable to react appropriately.
When applied to business, a company that can react to changes in its market faster than another company is likely to be more able to capitalize on those changes. This is especially true of the software industry. One software company may require a year or more to react to demand for a new feature. A competitor which only requires 3 months to implement a similar feature obviously has a major advantage. Even if it takes a year for both companies to implement the entire feature, the second company is free to offer incremental updates that build towards that feature meaning happier customers, and a chance to steal customers away from the other company if the feature is highly desirable.
The OODA loop concept got me thinking about speed of iteration, and how I could speed up some of my processes.
Countless times we find ourselves working on a feature or bug fix, only to be interrupted to investigate an on site issue. This often requires the set up of an environment where the issue can be reproduced. This might include getting the correct version of the source code, restoring a database backup, ensuring that IIS is configured to use the correct virtual directories for the correct web services, checking log files, and so on. This can be an error prone process and is time consuming. It’s also difficult to commit some of these processes to memory, as the need to use them occurs infrequently. You end up having to learn the same things over and over.
The majority of time spent in situations like that is not necessarily spent what I’m actually being paid to do – find and fix a bug. I don’t want to mess around in SQL Server Management Studio and IIS. I’m here to understand a problem and write code to correct it.
If only I’d applied my coding skills to my own problems as well as those of our customers. That feeling of annoyance when I have to perform those mundane administrative tasks is my subconscious, recognizing the fact that repetative tasks are exactly the kind of thing that should be performed by a program. Database backups can be taken care of with a simple executable with .bak files associated with it. IIS reconfiguration is easily done through .NET code. Log file searches or aggregators can be written quite simply using a scriptable language like F#. In fact, F# interactive is my favourite tool to take care of many of these types of tasks.
Individual improvements like the ones mentioned above free your mind from mundane tasks and allow you to focus on getting a real job done, speeding up the time it takes to switch from working on one task to another. The next time you’re faced with some mundane task, ask yourself if you can get your computer to do most of it for you.