I'm sitting here watching "Extreme Engineering" on the Discovery Channel. This episode is about Boston's Big Dig, a project to move Interstate 93 from above the streets of Boston to beneath them, as well as extend Interstate 90 (under Boston Harbor) to reach Logan Airport. The number of people involved, projects being managed, and unexpected problems that they ran into, is absolutely astounding.
Despite an insane number of constraints--the tunnels needed to run under the above-ground rail lines, beneath the one of the underground red line subway stations, and over the red line tunnel that was running under Boston Harbor itself--as well as the inevitable Feature Creep you get when $10B+ is being spent (I think they're up to $15 billion dollars) and politicians are involved, they're pulling it off. Without shutting down (Though they are slowing things down in spots) the existing highway and street systems. The system is mind-boggling, and has been going for more than a decade, and they're pulling it off.
We, on the other hand, can't manage to build a PC operating system that doesn't suck dead badgers through 12" metal conduit.
Not that this is an entirely fair grump, as there's a lot of software involved in building and managing the Big Dig and the tunnel maintenance and monitoring systems. I can only presume it's not being designed and managed by hordes of over-caffienated, ADHD programmers and clueless managers.
It would be so nice if we actually looked on building big projects in our profession as an engineering discipline, rather than some sort of work of abstract expressionism, or cowboy dickwaving contest.
Posted by Dan at May 29, 2003 11:32 AM | TrackBack (1)Hmm. Decide to do a project only because "it's not our money". Allow
creeping featuritus and lousy project management. Exceed multi-year
and multi-billion dollar time and cost budgets by small integer
factors. Declare "success".
Give me $3B, er, $15B US, to build a PC operating system,
and its dead badgers will play calypso on pans.
That's probably more money than has been spent on OS software
engineering, cumulatively, since ENIAC. ARPA's annual CS budget is
only up to what, something like a half billion?
But yes, software engineering is a disaster. Poverty and
self-inflicted ignorance and stupidity is a potent brew.
I sometimes wonder whether, if one were given 1 to 10 $million per
year, to redistribute as small targeted grants, one might dramatically
reshape the historically dismal pace of software evolution. Ah well.
Hah, I'm starting to think the opposite. Treating software projects like engineering feats *is* the problem. You show me one project with design specifications of sufficient detail requiring hundreds of man-years of work and guarantee that they're never going to change and I'll show you a million projects where that'd never work.
And yet, somehow, a lot of people keep trying just that. There's a word for software that can't change — it's hardware.
Posted by: chromatic at May 29, 2003 04:42 PMSoftware isn't engineeering. It just isn't. It's not art, and it's not science. It's a craft, much like carpentry.
Art is about the pursuit of beauty. While beauty may be present in code, code is useless unless it solves a problem; beauty, if it exists in code, it's secondary.
Science is about discovering the fundemental limits of what is possible. That certainly doesn't describe software, because the limits are bound by creativity, not G or Plank's law.
Engineering is about solving problems, but software is also about learning from past projects and improving upon them. Software isn't anything like bridge building; a bridge builder can study other bridges to see (a) what went wrong, (b) what's worth copying and (c) what's likely to work here. When was the last time you saw a lead software developer start with a code book and determine the factors a piece of software absolutely must meet in order to succeed?
Crafts, on the other hand, are interested in building artifacts. Sometimes those artifacts, like chairs, can be beautiful by design; sometimes they can have an accidental beauty, but mostly they're built to solve a problem (having a place to sit down).
One reason why software is so crappy is because no one is really studying the craft - everyone's a master whittler, and no one would ever deign to be an apprentice.
Posted by: ziggy at May 29, 2003 05:50 PMI found the set of articles at The Programmers' Stone very interesting.
The author discusses the craft vs. engineering theme a bit further and explains why and how (some) programmers get their ideas.
Worth reading IMHO
The reason we can't build a decent OS (and feed the poor or have peace I might add) are political and not technical.
This could have been solved 15 years ago but:
1. It is hard to make a living working on Free Software.. (and will continue into the near future)
2. There are some assholes like Microsoft who want to control the world who don't play by any rules and continue to fuck up technology.
Get rid of issues #1 and #2 and we could build some really cool stuff!
Posted by: Kevin Burton at June 2, 2003 04:55 AMThey might pull it off, it might get done according to specifications, but they still one big problem that you find in most software projects:
Scalability.
What are they going to do if the bandwidth just isnt big enough. Dig more holes.. and that's not gonna happen over night.
I "enjoy" driving through the elbe autobahn tunnel in Hamburg every day. It is 6 lanes right now, with two more coming at the end of the year. And you can be sure there willstill be at least 4 hours of traffic jam every god damn day.
Posted by: malte at June 2, 2003 10:13 AMi just was to ask that whether software engineering is really an engineering? if not or if yes than why?
Posted by: shumaila at September 8, 2003 04:10 AM