We build bridges in times of peace. They take a long time to build; they tend to last a long time, but sometimes they crash. We also build bridges in war-time. Working in the face of enemy fire, they get built really quickly, and tend to serve the purpose well.
What is war-time software? Are there methods that enable us to build software in a fraction of the usual time in highly competitive circumstances, while still serving its purpose well? The answer is yes.
Peace-time bridge building
The bridge over the Firth of Forth in Scotland was the world's first major steel bridge. It took about seven years to build, was completed in 1890, and is in use to this day.
(Credit)
As many as 4,000 men worked on the bridge at a time, with 57 losing their lives.
The Golden Gate bridge in San Francisco is more recent, having been completed in 1937 after about 4.5 years of work.
(Credit)
Peace-time bridge building: the results
I've given just a couple of examples, but they are typical: bridges take years to build in peace-time, and people die while building them. And while we expect them to never crash, in fact they do. It's not as rare as you may think! Here's a collapse of a bridge in Canada in 1907 killing 95 people:
The Silver Bridge was built in 1928 over the Ohio River. Here is in when it was completed.
It collapsed in 1967 during heavy rush hour traffic. 46 people were killed.
And here's a portion of the Route 95 in Connecticut that collapsed in 1983:
There are many more examples. Peace-time bridges take years to build and are expected to work without problems, but in fact they sometimes collapse and kill people.
War-time bridge building
Building bridges in war time is a whole different matter. The bridges aren't allowed to collapse and kill people any more than those built in peace-time, and the loads they're required to carry can be much greater. Frequently they are built under enemy fire. Yes, they look different and are constructed using different techniques:
(Credit)
But that's the whole point. The time constraints are severe: instead of years to build a bridge, it must be done in days.
Here's the story of the bridge pictured above:
It was during this week, in late March of 1945, that the U.S. Third Army under Gen. Patton, began its famous bridging and crossing operations of the Rhine.
The first unit to cross was the 5th Infantry Division that used assault rafts to cross the raging Rhine ... in the early morning hours of March 23. ... By 1880 that evening, a class 40 M-2 treadway bridge was taking traffic. The following day, a second 1,280 foot class 24 bridge was completed in the same area. It was later upgraded to a class M-40 bridge. Without the benefit of aerial bombardment or artillery preparation, units landed quickly and established a beachhead that was seven miles wide and six miles deep in less than 24 hours...When daylight came, the Luftwaffe attacked the enclave with 154 aircraft in an attempt to dislodge the foothold on the east bank. Effective anti-aircraft fires brought down 18 of the attacking planes and destroyed 15 more.
By March 27, five divisions with supporting troops and supplies had crossed the three bridges constructed at Oppenheim. The entire 6th Armored Division crossed in less than 17 hours. During the period of March 24-31, a total of 60,000 vehicles passed over these bridges.
Peace-time software
Most of the software built today is built using "peace-time" methods. Those methods are so ubiquitous that they are simply considered to be "the right way to do things." We document everything. We have a nicely, orderly flow from requirements through design, coding, testing and deployment. Whether waterfall or "agile" is used, everyone is given time to do their job, and frequently asked how long it will take. Estimates are critical, and the most important thing is delivering on the expectations you set.
In this environment, it's important to make sure your estimates are long enough to account for things you forgot about. Taking a long time to get a job done isn't a problem; taking longer than you said you would take is the problem.
War-time software
So what is war-time software? It's a looooong subject, and can't be done right in a short post. But the principles should be obvious from the bridge-building metaphor:
- Time is the most important thing; if you take a year to do what the other guy gets done in a month, you've lost the war.
- Solving immediate problems is far more important than effort put towards some imagined future.
- Something is better than nothing.
- Finding and fixing problems is more important than preventing them.
- Did I mention that nothing is more important than speed, except possibly avoiding getting killed (usually)?
Those war-time bridge-building guys made it up as they went along, but they couldn't have done it without an elaborate tool kit, appropriate supplies and matching skills and procedures. The scene on the river may seem chaotic, but there's a pattern and lots of coordinated activity, with everyone working towards a common goal: the least they can possibly do that gets things safely over the river. When is peace-time software ever subjected to that kind of parsimonious discipline?
War-time software development is development that is organized and optimized for speed: getting the least acceptable solution built and deployed in the shortest possible amount of time, and rapidly iterating from there. And then doing it again. Obviously, you spend time gathering and organizing your supplies and improving your technique.
War-time software is not doing things the usual way, only skipping steps, doing things sloppily and writing half-done crap code. That's doing a bad job using peace-time methods. War-time software is doing things in a war-time way using war-time techniques.
Conclusion
Are you truly operating in peace-time? Is your competition frozen? Do you have no time constraints or money limitations? Then, by all means, continue to use peace-time software methods -- take huge amounts of money, incredible amounts of time, document and plan and manage everything with precision, and build your software. Software that will crash when you least expect it.
If, on the other hand, you are at war, and if you, you know, want to, like, survive -- well, you may want to consider building software that actually meets the immediate need.
Find a way to get that data, those screens and workflows over that threshold, soldier. Now! Yes, I know that in your previous life, it would have taken you a week to write a proposal for creating a plan to get it done. These screens, workflows and databases are going to be on the other side of that threshold in under a week, while enemy forces and programmers are doing their best to kill us in the marketplace. Move it!
War-time software. It's the way to win.
Comments