What does a foot soldier have in common with a rank-and-file developer?

What does a foot soldier have in common with a rank-and-file developer, a platoon leader with your manager, or General “We'll Sacrifice the Left Flank” with a crisis manager? I like reading about modern military affairs and warfare. At first glance it may seem miles away from software engineering. In fact the two have a lot in common. Warfare, or the art of war, is seen as barbaric, but look closely at its principles and patterns and it isn't so different from software development. Military operations and campaigns often use similar metrics and are managed and, above all, planned much like many software projects. Over the years my bookshelves have filled with titles about every battlefield in modern history, from North Africa through the Russian steppe to the jungles of Southeast Asia. In many cases you could change a few details, swap soldier for developer, campaign for project, and manager for commander, and you'd have stories straight out of our own field. Fortunately for us, the consequences aren't fatal.

Military work is a craft

The information technology industry as a whole has been evolving for a few decades, give or take. The military has a head start of two thousand years and a few centuries. It had to evolve and respond to everything from advances in science to political whims. Software development was shaped by the internet and mobile devices, just as the military was shaped, for example, by advances in aviation. The military has always learned by reflecting on its mistakes, as we learn from ours. A feature of military thinking, or so it seems to me, is the retrospective. It investigates how something happened, with the benefit and distortion of hindsight about why it happened or what might have happened. In software development we settle for knowing that something went wrong and seldom look closely at why. Few people will say that they did it badly and spell out the mistakes they made.

Blitzkrieg and DevOps

DevOps, which has been discussed at length lately, is about bringing separate specialist groups into a functioning whole. It has a military parallel.

Until the start of the Second World War, armies were traditionally divided into arms such as tank units, infantry, artillery and aviation. Each had its own command, and they coordinated on individual operations. The Germans came up with the idea of deploying these arms together to maximize their effectiveness. Deploying tank units with direct support from aircraft and infantry was the foundation of what became known as lightning war (Blitzkrieg), and it played a decisive part in the successes of the early war years. The Allies later tried to copy it with varying success. Along with greater effectiveness, it cleared up problems of planning and command by removing the need to coordinate several independent structures. DevOps points out that an organization divided into specialist silos such as QA, Development and Operations is less efficient and makes planning difficult and ineffective. It seeks to integrate those parts as closely as possible into a functioning whole, making the organization more effective by bringing its teams together.

One man

You can look at a military operation from many angles. Tactics and operations, training, equipment and weapons, troop numbers, terrain and weather, intelligence on the enemy and so on. You can look at a software project in much the same way. Development methodologies, tools such as IDEs, compilers and languages, the complexity of the problem, the number of developers, and the hardware available. But take apart a military operation and look at each success or failure along the way and you'll often find that a very small group of men, or sometimes just one, played a decisive role. It's almost unbelievable that in a chain of events involving tens of thousands of people, the initiative of one person can tip the scales. When the Allies tried to land at Omaha Beach at dawn on June 6, 1944, they were in deeper trouble than they could have imagined. Enemy fire pinned them down with no prospect of moving inland. Most soldiers had trouble even reaching the beach. If they didn't drown, their weapons did. They expected second-rate troops weakened by bombardment and faced a well-trained enemy that hadn't been troubled by the earlier Allied air raid. At the height of the crisis, General Norman Cota landed in one sector. He knew immediately that if they were still on the beach that evening, the Germans would sweep them away. He gathered literally a handful of soldiers, explained that they were sure to die on the beach, and together they made the first passage through the barbed wire and minefield. That action by one small group prompted other soldiers to act and contributed decisively to the success of the landing. The story illustrates a simple point. Equipment, plans, calculations and even numbers of men alone don't determine success. That applies to software projects, too. That's why it matters to have motivated, capable people. We shouldn't be taken in by supposedly perfect plans, methods or tools.

Command depends on communication

German training in command and issuing orders followed a simple principle. An order stated what had to be done and left out how to do it. Lower-ranking commanders could assess the local situation and choose a way to carry out the order. The principle applied all the way down from the highest command to the squad. Every soldier was drilled to show initiative in place of waiting passively for instructions on how to do something. This was a major difference from the Russians and, surprisingly, from the Americans and British too. If a unit lost its commander, the whole mission was at risk because the unit lacked precise orders on how to carry it out. The Germans could retain their agility despite comparable or greater losses among their officers. This simple principle of telling people what to do and leaving the method to them applies anywhere. What your boss asks of you, and what you ask of someone else, should emphasize what needs doing and play down how to do it. People on software projects often get frustrated because all they do is carry out someone else's instructions. Give them room to work and use their creativity to fulfill their assignments, and they'll feel more motivated and responsible. Both sides benefit. Emphasize how too much and you'll soon fall into the trap described next.

Detailed planning and the friction of war

The Prussian general and military theorist Carl von Clausewitz, whom you may know indirectly from the phrase “war is the continuation of politics by other means,” wrote On War, a classic of the military arts. In it he first defined friction in war, essentially random and unforeseen events that make the army's work harder. Friction arises from the difficulties of turning orders from command into concrete actions. Another fine quotation describes its effect: “No plan survives first contact with the enemy.” The same goes for planning in software development. A plan can be excellent and worked out down to the smallest detail, but it can never allow for everything unexpected. That is why the earlier points about creativity, agility and initiative matter. They let us handle events we didn't anticipate. In war, politicians should set the campaign objectives and let soldiers decide how to achieve them and what means to use. In software development, management should likewise set the goals and let engineers choose the means and methods. Unforeseen events are decisive in special operations, for instance, when a small group of soldiers manages to overcome a much more numerous enemy. In his book on the subject, William McRaven analyzed the most significant special forces operations of the twentieth century. Along with surprise, a key factor they all shared was a novel use of some piece of equipment or an outright technological innovation. It let attackers overcome the defenders' conventional measures. One such innovation equipped the Italian frogmen who got past anti-submarine defenses and entered Alexandria harbor, where they used piloted miniature torpedoes to sink Royal Navy ships. In software projects, too, we often try to break through a wall with our heads and conventional techniques when we could climb over it with a ladder.

Schwerpunkt and limited resources

Schwerpunkt was the German term for the main point of attack. Concentrating all their forces there could create a local breakthrough, cut off the enemy's rear units and bring victory even when the enemy was stronger, held a better position or had another advantage. I often feel we lack a Schwerpunkt on which to focus all our resources. Instead we scatter them among more or less important tasks without a decisive success or breakthrough. If we often feel short of people and think our brief keeps changing, soldiers have been in much the same position, then and now.

Conclusion

I wanted to point out a few parallels between military affairs and software development. There are more similarities than you might think. We can look for inspiration all around us, because most of the problems we face aren't unique to our field. Working with people, planning and management, and making effective use of resources are all common factors. I'll also pass along What Companies Can Learn from the Military, the article that inspired me to write about this.