次の方法で共有

Software: Engineering or Craft?

  • [アーティクル]

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.

"urn:schemas-microsoft-com:office:office" />

 

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.  = "urn:schemas-microsoft-com:office:smarttags"
/>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

Comments