IAmTheRockstar

Yes. Yes I am.
You are accessing the archives. Commenting has been disabled, and archive posts are likely to be horribly out of date and, in some cases, rendered oddly because the styles from archive posts are no longer being maintained.
November 9, 2007

Building Bridges, Writing Software

I'm currently reading Scott Rosenburg's book entitled Dreaming in Code. I've really been enjoying some of the points he makes, and since he was in somewhat of a management position for the duration of the story being told, it provides a bit more project management insight as well as general development best practices.

The following excerpt from the book is what originally grabbed my attention to read the book:

If the subject of software's flaws is discussed for more than a few minutes at a time, it is a certainty that someone will eventually pound a fist on the table and say, "Why can't we build software the way we build bridges?"

This is not a new metaphor. I had quite a few professors in school that repeated this cliche almost as a mantra. When I first heard the metaphor, I thought "Surely, we must be able to write software like we write bridges." This thought was then followed up by "There are bridges that have bugs in them as well." Yes, my naivete was somewhat difficult to overcome. I wanted software engineering to be a wonderful and fun world (which it is now, but for different reasons).

Neal Ford wrote a post entitled Building Bridges without Engineering where he asserts his resentment for these metaphors, and then uses one:

Or it may just be that software will always resist traditional engineering kinds of analysis. We'll know in a few thousand years, when we've been building software as long as we've been building bridges. We're currently at the level in software where bridges builders were when they built a bridge, ran a heavy cart across it, and it collapsed.

This my exact thought while reading the phrase in "Dreaming in Code." I have worked in network administration and software engineering since I was 16, and has been the sole source of employment for me, so I hadn't thought, before reading "Dreaming in Code" just how young the software development world truly is. They've been building bridges for centuries, while we've been building software for decades. There is quite the possibility that hundreds of years from now, we could be using software engineering as the likeness to some other, newer form of engineering. "Doing Foo is like writing software..."

More recently, Ivan Moscoso over at Agile Ajax adds some insight with Software Development Is Like A Tortured Metaphor.. In it, Ivan details just how bad the engineering metaphors are when comparing them to software engineering. This is rather true, but not completely true. Engineering has some general rules that should apply to everything. Engineering software, engineering jet engines, and engineering bridges all have some general rules, but the specifics vary quite a lot.

Despite all of this gloom and doom though, software engineering is getting better! We have better tools, better languages, and better knowledge. Just a few decades ago, and bug in the system was just that: a moth flying around inside the computer. Software engineers also adapt well. The laws of physics don't change, period. Bridge building has to adhere to non-changing laws. But we get new processors with more capabilities, more cores, and completely different architectures every year. Software engineers must adapt to these new platforms. Heck, I've been writing C code for an ATMega128, which is yet another platform, even though it may not be a completely new interface. Bridge builders have one platform, we have many.

Maybe, in the future, hardware development will slow down, and we can perfect software development on just one platform before a new platform comes out. I guess I can continue dreaming...

No comments have been posted yet.
Comments are now closed an archived posts.

All opinions expressed here constitute my personal opinion, and do not necessarily represent the opinion of any other organization or person, including, but not limited to, my fellow employees, my employer, its clients or their agents.