In traditional architecture, planning is essential. Certain things unequivocally have to happen before others. Studs go in before plumbing. Plumbing is installed before the walls. The walls have to be there before the paint. Undo, Cut, or Revert aren’t viable options when building a skyscraper.

The software Undo is Ctrl+Z. The software Cut is Ctrl+X. The software Revert is a code rollback in source control.

Without the luxury of these very simple yet powerful gestures, buildings require very detailed specifications. One foot short is the difference between a profitable piece of real estate and a catastrophic front-page headline.

Let’s pretend we’re traditional architects afforded all the shortcuts of software development. It would be a dream world. Materials would be infinitely available. We could build a life-size model of a building in a few weeks. We could stress test suspension bridges over and over again. If a bridge broke, who would care? We could instantaneously replicate ten new ones in a few minutes!

Of course, all of this is mere fantasy. So, writing specifications in excruciating detail makes the most sense when we’ve decided to build a skyscraper.

On the other hand, these are the luxuries of our industry. Software components don’t need to wait on a shipment of letters and numbers from the local factory. We type, compile, test, and repeat. We can test code on the real product, not some model of the real product. We have the luxury of watching our suspension bridges break hundreds of times while in development, in all different places, under all different conditions, without the worry of wasting materials or putting people’s lives in jeopardy. Working this way is completely feasible. When we finish software, the same application can be duplicated 1,000 times with negligible human effort.

When the developers of the Wynn Hotel in Las Vegas built a virtually identical twin hotel called the Encore in 2008, they didn’t have the luxury of copying and pasting the first version into the vacant lot next door. They had to start with specs and planning just to build a nearly identical structure.

Even when software meant shipping code on a disk, planning extensively still made a lot of sense. Meanwhile, web-based software is a different game. Planning through very detailed specifications prior to writing a line of code still has merits, but it doesn’t fully take advantage of the medium. We can release new builds daily or hourly or whenever we want, with very low overhead, from the comfort of our cushy Aeron chairs.

Fortunately, as an industry, we’re starting to break through the metaphor. Agile development isn’t revolutionary; it’s just untying us from a metaphor that doesn’t make as much sense today as it did in the past. That’s not to say that traditional waterfall development is obsolete. It still has its merits on larger, more complex software projects. But following that metaphor without question might also blind us to an approach that better fits the medium we work in.

The “plan, plan, plan” metaphor overvalues the time we spend trying to get everything perfect and undervalues the time we could be spending writing the actual code.