For as long as I can remember, people have been comparing software to construction.

"Continuous design is impossible. You can't add a foundation to a house after you've built it."

"Would you build a bridge without planning it carefully first?"

"I'm an Architect."

At the risk of being rude: Software development is nothing like construction. Nothing!

Outside my window, at this very moment, I'm watching a team of people do a fine job of building some sort of large building. I'm guessing it's going to be a condominium.

And I gotta tell you, I'm not seeing any typing going on over there.

Here's what I have seen: First, some backhoes came along and demolished the existing structure. Then the timber and bricks and nails and stuff were loaded into dump trucks and hauled away. Next the ground was leveled. Then the site just sat there for months.

Since people love to compare software development to construction, I would hope that there would be some obvious lessons to be learned from what I've seen so far. But I'm having trouble seeing what demolition and earth-moving teach me about developing software. I suppose I could make up some tortuous analogy, but I wouldn't learn anything except the fallability of metaphor.

Okay, maybe the "software is like construction" metaphor refers to something else. What happened next? Well, after months of waiting, some guys showed up and dug trenches in the road. They laid some pipes and then covered it back up with gravel and asphalt. Meanwhile, a big trench was dug in the dirt and concrete walls were poured on each side. Some pipes were put in the middle and the whole thing was covered up with gravel.

A metaphor-loving "architect" might point at this and say, "Yes! See, that shows how important a proper foundation is!" I don't get it. To me, it says, "if you're going to put something in the ground, dig a hole to put it in." But... it doesn't take a genius to realize this... there is no "ground" in software development. What would it even mean to "dig a hole" in a piece of software?

After the Great Hole Digging Experience, there was more waiting. Then, just this week, a bunch more people showed up. They built the frame of each wall on the ground, then levered it up to form the walls of the building. Then they nailed boards across the tops of the walls to form the frame of the ceiling. Today--yep, they were working on a Saturday--they added plywood or something similar to the frame to form solid walls and ceiling.

Again, I just don't see the comparison. What does software development have to learn from framing a house? Do we build our pieces of our software on the ground, then lever it up to form walls? Do we nail plywood to the frame to keep out the wind and rain?

The Point of This Rant

Ultimately, construction is about dealing with physical objects. It's about big, powerful earth moving equipment. It's about muscles and hammers and nails and being just one step away from falling off the roof. It's sexy.

Software is not physical. It's certainly not sexy. All I have to do is answer the question, "What do you do?" at any party to learn how absolutely uninteresting my chosen profession is. I say, "I work with software," and the questioner visibly glazes over and turns to the next person. (Or worse, they grill me about using Photoshop. I've never used Photoshop in my life.) I've come to dread that question.

People in the construction industry do things for physical reasons. If they dig a hole before laying a concrete floor, it's because the hole has to go under the concrete. If they build the wall frame on the ground, it's because it would fall apart if it weren't.

In the software world, there is no reason for us to follow the practices of an industry limited by Newtonian laws. We have no gravity. There is no inertia. Lines of code have no weight.

If we want to dig a metaphorical hole after pouring metaphorical concrete, there's nothing to stop us. If we want to flip the software upside down and build a foundation after we've built the building, we can do it. Our only limits are in our heads. Once we stop thinking that software development is like construction, we'll have one less limitation to struggle with.

PS: Jack Reeves has a classic essay along these lines that's a must-read.