Software "Engineering"

It seems like every time someone talks about the job/craft/calling of writing software, they tend to end up with a bunch of tortured metaphors (engineering, woodworking, rock climbing, gardening, etc.). None of these analogies hold up past just superficial scrutiny. I think that it's a reflection on how different it ultimately is.

But to use one of these tortured metaphors for a moment, think about bridge building. I had someone at No Fluff, Just Stuff Philly say that her company had starting outsourcing much of their coding to India. I asked her how they judge the quality of the software. She said that she looks over it, and they have a software architect that comes to look at it periodically. Unit tests? None.

What if you decided to build a bridge? You outsourced all the design to guys who say they can build bridges, and you have someone who has built a few bridges look over the design when it comes in. Would you drive over that bridge? What makes bridges safe? It's the engineering science behind the bridge -- the mathematics of structures, derived over a great many years. So, why don't we apply the same rigor to software? We can't. We don't understand enough about it to quantify it in that way (and may never -- that's where the engineering metaphor breaks down again).

So, what's a poor developer to do? Actually, we do have a great option -- testing! It's extraordinarily difficult to build all the parts of the bridge and test them individually, then test it as a whole. However, because software is so soft, you can test everything. And you should. That's as close as we can get now to the rigors of a "real" engineering discipline. So we'd better damn well start doing it!