small medium large xlarge

Trench Warfare

Is Your Software Project in the Trenches?

by Jared Richardson

Generic image illustrating the article

Trench warfare has been used for centuries, but it has become firmly associated with World War I. Although used throughout the ages, sometimes with great success, trenches never became a standard military tactic. Then, in WWI, there was a perfect storm of technological advancements that made trenches an essential front-line military doctrine and a killing field for the average soldier. Sadly, that’s why they’re so similar to today’s software shops.

There were two key factors to the popularity of trenches on the front lines of WWI. The first was the machine gun. The ability to install a gun emplacement that could mow down soldiers required some sort of defense. Trenches were the cheapest way to escape the bullets, and dirt was cheap. There were only two things the front line generals had in abundance: dirt and soldiers. So they dug trenches until they were close enough to a target (such as a machine gun nest), then soldiers poured out of the trench and overran the position. In terms of human life it was a costly maneuver, but effective. It was impossible for a single gun emplacement to shoot that many men.

That leads us to the second advancement that made trenches popular: concertina wire. We’ve all seen this nasty form of barbed wire. It’s a curling, circular wire fence that can be quickly uncoiled to cover a large area. Today we usually see it on the top of a chain link fence at a prison. On the front lines of WWI, it was stretched out on the ground. When soldiers poured out of their trenches, they’d get tangled in the concertina wire and the machine guns would mercilessly mow them down before they could escape.

The machine guns and concertina wire lead to enormous trench systems and an enormous stagnant front. Thousands of men massed within sight of each other, but dared not lift their heads out of the trench. Neither side could make significant progress, so the troops sat in the same trenches for weeks, or even months, at a time. In hindsight, the results were rather obvious: the foul conditions in the trench lead to “trench foot,” lice, dysentery, and an assortment of other nasty side effects. It became a war of attrition and your own trench became the weapon that was beating you into the ground.

In the Trenches

All of which reminds me of so many software shops today. Recently, I was speaking to a Fortune 500 company about a full-time job as a process guru. I’d be helping to change the way their developers worked from top to bottom. We’d be affecting the efficiency and productivity of thousands of developers. This company couldn’t deliver products on time, quality was bad, and morale was low. They needed someone like me. Obviously I wasn’t the only person who could fill the role, but they needed someone to work in that capacity and they needed them quickly.

As we were, I thought, about to close the deal, I was told that they were having trouble justifying my position, but they could start me tomorrow if I had any “web 2.0 coding experience.” In other words, instead of hiring someone who would step back and look around and try to find a way out of the trench, they were only interested in hiring someone else to jump in.

A depressing theme with many of today’s software shops is the need to only make two kinds of hires. The first is a developer. After all, a developer codes, and that makes money! The second hire is an MBA-style manager. This manager is an HR-type who handles budgets, spreadsheets, and politics.

Then someone like me comes along. I’ve got a development background and I’ve managed as well, but today I don’t do either. Instead I work with a team to see where the problems are. I sit with them and look for the areas that have become blind spots, and then find ways to solve those problems. I’ve saved large organizations substantial amounts of money by improving how their teams work. But I’ve usually done this by hiring in as a developer or manager. It’s a rare company that hires someone to improve their process. They’d much rather sit in the trenches and inspire their soldiers to leap out in the face of concertina wire and machine guns, sure that with the right mix of courage and moral fiber, this time they’ll finally ship that product!

As we look around, this attitude seems so… stupid. They seem to think that by trying harder they’ll succeed. How many of our favorite sports teams don’t have coaches, but ask their professional athletes to try harder? Note: I’m not talking about managers, but coaches. Olympic-level track and field athletes have individual coaches. What do they know that software companies don’t?

Companies spend an insane amount of money on software teams. Many spend millions of dollars on their people, then take a thousand steps backwards to a Victorian attitude that their teams are smart enough to solve every problem. It’s quite likely you’ve hired some very smart people, but since you’ve had them heads down in the trenches for the last several years, it’s possible they’ve missed a few trends in software. Buying a book or two, or allowing a senior developer to attend a conference is fine, but it doesn’t equate to training your team—any more than granting shore leave to an officer equated to a better rested platoon.

And before this starts sounding like an ad for my services, I have a full-time job and am not on the market. I’m just trying to address a glaring blind spot I’ve seen in far too many companies, if not the industry as a whole.

The Trench Shop

So let’s step back a bit and think about trenches. What does a trench shop look like? I realize that there’s no real comparison between someone dying in a killing field and burning out at our day job, but we can still draw some meaningful parallels. It’s a metaphor. Let’s see what we can get out of it.

  • Trench companies don’t want strategic hires. They want more developers who will work overtime until they burn out. They don’t want to hire anyone who can or will think, they want people who already know technology XZY so they can hit the ground running from day one. (That’s an interesting thought… beware of companies who always have openings. Why do they ~always~ have openings?)

  • After spending too much time with your head down in the trenches, you start to notice little problems. Like rotting feet. Your builds are always broken, but that’s okay. You’re not shipping this year anyway.

  • You’ve heard about newer, more productive technologies, but don’t have time to learn them. You’re too busy working, so you can’t learn. Hmmmmmm…..

  • There’s a local conference, but you can’t go. You’re too busy working that week. And that weekend. Don’t even think about asking to attend a regional or national event. That would just be silly.

  • You know that things would run smoother with an automated build and deployment, but that feels like a pipe dream. Something people write about in articles and books, not something people do in real life.

  • You know that decent test coverage would save you hours in debugging, but you’re so busy debugging, you don’t have time to write the tests.

I could go on, but the real problem here isn’t the developers; it’s management. They continue to hire trench grunts and smack down anyone who raises their heads. We’re already dealing with constantly shifting operating systems (another service pack anyone?), newer versions of browsers and languages, and customers that constantly change their minds. Do we also have to deal with tactics that our military discarded nearly a hundred years ago?

If you’re happy putting your head down in the sand and being an ostrich coder, then stay in a trench shop. Enable these bad managers to continue squeezing profits out of your blood and ulcers. Or—here’s a thought—get out. The economy is bad, but most software shops I know are still hiring developers. We’re fortunate enough to be in a market segment that’s still growing, and there are jobs available. Until we stand up and get out of the trench, no one will be forced to consider it a bad practice.

As long as it’s winning—I mean profitable—why change? 

Jared Richardson is an author, speaker, and developer who lives in North Carolina. He started Agile RTP, now the largest Agile user group in the United States with nearly 700 members. His first book, Ship It! A Practical Guide to Successful Software Projects, is a best seller and is now in seven languages. He spends his time playing with his family and recently, rather by accident, became a backyard chicken farmer. You can find him on the web at
