The Right Metaphor

If you haven’t caught Kyle Wilson’s recent piece, “Software is Hard,” I highly recommend it. The essay moves elegantly from book review, to musings on knowing when the code is “done,” to issues of measuring quality, to the ever-present problems of lateness and going over budget, to the potential inadequacy of “engineering” as the metaphor for writing software.

It’s the last topic that’s the most fascinating to me. Kyle points out that new software is written only in response to new problems (otherwise, you’d just use existing software). As such, new code ventures into the unknown, where you can, at best, only guess at the challenges you’ll encounter. We always try our best to assess what we’ll face, but by their very nature, these are imperfect assessments. As Kyle puts it, “The only way to avoid that is to have your design go all the way down to specifying individual lines of code, in which case you aren’t designing at all, you’re just programming.”

Which is not to say, of course, we should simply give up engineering. Without some sort of plan for design and advance assessment, we’d be utterly lost. Businesses couldn’t function and programmers couldn’t make a living. For better or worse, the smooth functioning of our society is founded on the arrogance of making accurate predictions, not just about business and software, but about everything from politics and law, to human behavior and psychology, to weather. Such hubris…

No surprise, then, that even real-world traditional engineering often fails to be predictable. Kyle mentions the Oakland Bay Bridge as a project that’s hugely over time and budget. Just yesterday, Boeing announced its much-anticipated Dreamliner would be six months late.

So maybe software engineering IS the right term after all.