[lug] software engineering

[bgiles at coyotesong.com]

The heart of engineering is making an informed, economic decision on the
most cost-effective use of resources.  That means knowing when to invest a
lot of effort into design and implementation validation... and knowing
when not to.  It's perfectly reasonable to say that something isn't worth
investing a lot of effort.

The key point is -informed decision-.  How many of our decisions are
properly documented?  You wouldn't want to do this with a 5-line perl
script to monitor disk usage, but how many of us could successfully
convince our boss to invest a few hours every week in documenting the
basis for our decisions?  (N.B., not designs or implementations, but the
decisions we made plus a brief justification.)

I think that's the biggest problem with software today.  Not that it's
released "too early", that it's released without really thinking things
through.  Different people and group makes their own "best" decisions but
they aren't always playing to the same goals -- that gives you
inconsistencies and flakiness.  You would never see a civil engineering
project that deliberately built a six-lane road up to a two-lane bridge.

> On Sun, 2006-11-12 at 23:44 -0700, Nate Duehr wrote:
> Software gets a bad rep because it isn't as critical to get right the
> first time as building a bridge, and it is easy to update and fix later,
> so perhaps less effort is put into verification.  But the customer does
> get faster and cheaper in exchange for a few bugs.
>
> I would say really critical software, like F-22 flight control software,
> *is* heavily analyzed and tested, and is probably just as reliable as
> the mechanical engineering that goes into the wings and engines.