This post originated from an RSS feed registered with .NET Buzz by Chris Flaat. Original Post: Software: Engineering or Craft? Feed Title: Chris Flaat's Weblog Feed URL: /msdnerror.htm?aspxerrorpath=/cflaat/Rss.aspx Feed Description: I mainly discuss tips & tricks about VS 2002, VS 2003, and upcoming versions of VS. Latest .NET Buzz Posts Latest .NET Buzz Posts by Chris Flaat Latest Posts From Chris Flaat's Weblog

Software is such an interesting field.  We can’t figure out whether it’s a craft or an engineering discipline.  Personally, I think it should be an engineering discipline, but it’s one that’s fundamentally different from physical engineering like building a bridge or skyscraper.

Why should software be any different?  After all, skyscrapers and bridges are complex projects but you rarely see them fall down.  Why can’t that same kind of discipline be applied to software development?

One key problem is that software is an intangible thing that is fundamentally much more complex than inanimate physical objects like bridges.  A moderate-sized program has a vast number of states and subtle interdependencies.  And when someone wants to change a program, it can cause significant changes in how it works such that its behavior is fundamentally altered.

Another problem is that each computer program is both similar to and different from every other program.  A bridge, while it has to deal with different terrain at each instance, is really very similar wherever you go.  Its job is unambiguous, its load is based on well understood principles, and its scope is limited.

A computer program, on the other hand, is limited only by imagination and resources.  One of the hardest things about software is simply coming up with a clear definition of what you want, to say nothing about implementing it.  A program’s scope and function change all the time, and the program will often have to operate in different environments (different OS’s, different hardware, different languages, etc.).  Worse, you don’t know what kind of environments you’ll have to operate it five years from now.  With a ship or car you can at least test drive it in a known range of climates and have a good sense of how it will behave.  But how can you know how well your program will work on the next version of Windows or with the next generation of internet connectivity?

In time I think we’ll get to the point where software development is an engineering discipline.  But I cringe when I read about people (especially lawyers and lawmakers) making simplistic comparisons with civil engineering.  If making software into a mature discipline was simply a matter of more uniform codes and licensing, we’d have gotten much farther by now than we have.  The fact is that software development is a qualitatively different undertaking than these other fields, although that of course does not excuse us from trying to raise the level of practice up to that of these more established fields.

The Space Shuttle is often cited as an example of reliable software.  I once heard a talk by someone who worked on the shuttle software (which was not the culprit in either the Challenger or Columbia disasters – those were equipment failures).  They do a very disciplined job, designing every aspect of the program before a line of code is written.  However, their requirements don’t change very often and they are not in an environment where cost is the dominating factor – safety is.  This is entirely appropriate for the shuttle, but it’s not necessarily appropriate to assume that their budget environment will necessarily translate to a commercial software enterprise, where customers would tolerate more failures in exchange for paying $50 rather than $500 for a program.  (But even so, I do think improved processes & tools could significantly raise the quality of commercial software without requiring a tenfold increase in prices.)

That’s all for now! -Chris