Concepts from the military can often be useful to explain ideas in different areas like business or technology (as it is the case for this blog - the word “strategy” is deeply rooted in warfare).
For example, consider the role of a pioneer in the military.
Wikipedia 1 2 defines this type of soldier as follows:
Historically, the primary role of pioneer units was to assist other arms in tasks such as the construction of field fortifications, military camps, bridges and roads
Pioneers are enablers and fixers. They pave ways, fix broken infrastructure and secure beachheads. They often march in front of an advancing army to secure new terrain.
There are phases in a software development project that require a similar type of pioneering work. Often, this work is done by software architects.
Mostly two types of situations come to mind:
- The need for a proof-of-concept work
- Investigation of a notoriously difficult bug
Continuing with the metaphor, when we implement a proof-of-concept project, we are exploring new territory in the hope to secure a (strategically) important landmark. This can mean to make sure a new framework or platform works the way we expect it to do, trying out a new implementation of an algorithm or testing the feasibility of an idea.
Fixing a notoriously difficult bug is the equivalent of helping an army that got stuck by fixing broken infrastructure like bridges or train tracks. In the world of software development, this goes beyond mere bug fixing. I’m talking about a situation where debugging a problem has become so difficult that usual ways don’t work anymore. This can happen, for example, when, for whatever reason, a team had to make so many changes at once that the number of unknowns made narrowing down the problem impossible. In those cases, it can be better (or might be the only feasible option) to re-create the environment with only the minimum dependencies (or even less) and stripping away everything else. Starting new from scratch, or to be more exact, starting from the last known working state and moving towards the desired, non-working state.
Rules of pioneering work
- Pioneer code is meant to be thrown away. The moment we understand how the new framework works and that it does what we expect from it we are fine and can move on. Pioneer coding is coding to gain knowledge, not to deliver functionality.
- Speed matters. Code can be as ugly as needed because we only want to get from start to finish as quickly as possible.
- We need to keep the number of unknowns to a minimum. The goal is to move from one working state to the next.
- The second rule of pioneering club is … yes, really, the code is meant to be thrown away. It might be tempting to use the code as a base for a new project but as stated above, quick & ugly is the motto and we don’t want that as the basis for any serious development.
The downsides of pioneering work
- Expect reluctance from management because pioneering work can look like a waste of time and money.
- Expect reluctance from developers because being deliberately fast and forget rules of clean code can push some people out of their comfort zone
- Due to the uncertain nature of pioneering work, a higher degree of ownership is required. There is no clear specification or feature request which feel unmotivating for some.
The upsides of pioneering work
- It can feel like fun and play. It can be liberating not having to worry about code quality with the only goal to gain understanding
- Starting from scratch with only the bare minimum and everything else stripped away can lead to a significant understanding. Often, we can’t see the forest for the trees and just by starting small things become clear
- Deeper knowledge leads to deeper developer happiness. And helping others to get unstuck can be very rewarding