Bridges and Space Shuttle

Recently, on Joel on Software forum a thread discussed NASA decision not to fly the shuttle across an year change date. Being in space between the last day of the year and the first day of the new year is considered dangerous. This rose a debate on Space Shutte software quality.

An interesting article about the Shuttle software developement group can be find here.
The development group produces software with almost no bugs, they own a world record on this. The secret is a very, very detailed design upfront, for implementations an changes as well.

What is important about this methodology, in my opinion, is the fact that software design and coding start to look like the rest of engineering.
What's the difference between designing a bridge an a sw system? Both are complex and have a large number of interacting parts. The relations among these parts may be overly complex for both parties. The building process is not trivial and requires a large amount of organizational effort. Both may require trimming an maintenance, albeit what causes the need for maintenance to rise is different.

So, how comes that a bridge hardly fails but software is often buggish and a software project is less likely to hit the target?

The answer may come from seeing the Space Shuttle software group at work, they...

treat software like ordinary engineering.

There are comon engineering practices that are widely accepted, but not in software, that ensure the quality of work.

A very detailed design upfront is almost mandatory. Each real-world, industry produced, object has detailed sketches preserved in someone's drawer. Those sketches can be given to a technologist an be undestood. More, they fully describe the object. If required, technical relations come with them, stating all the production processes and calculations needed.

In almost every field of engineering there are rules or regulations to comply with. These, in engineering, are not thought as thethers. On the contrary, they are seen as the right way to do things. Design and build according to the rules and everything will work. You have no need to re-invent the wheel each time.

There are a lot of widely accepted standards that reduce compatibility problems to the minimum. There are no bolts on the market but those that comply to an accepted stadard. There are no car wheels availabe but those who fit codified sizes and performances.

None of the points above is common in software development. The cause is likely twofold.
Software development is young, modern engineering goes back to the 18th century, some time is required to let established rules and procedures emerge.
Software developers are young, and many of them think to software as way of life instead of an artifact like the others. This means that they tend to be a bit too much creative and suffer from any kind of constraint.

The last point would take us very far, and I'm not going to cover it more extensively in this post.
My point, anyway is the following:

whe should devote more efforts to software standardization and design, because software is more an art than a science, but it has been so for too long to find its way in modern engineering.