[lug] software engineering

[Nate Duehr]

bgiles at coyotesong.com wrote:
> 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.

How many engineers even know how much the product they work on sells 
for?  I guarantee a building engineer knows the rough costs of every 
material and various flavors of labor used in his or her end-product, 
and how to make sure the contracts are right so that the customer will 
pay for the appropriate things.  But in software engineering, I don't 
see many companies involving any but a very select few (usually already 
in management) engineers in the COST process.

Since we're talking about Linux and then maybe commercially purchased 
software... How do you find out just HOW MUCH testing was accomplished 
on your software before you received it, as the CUSTOMER?

That's my thinking line here.   How do customers find out?

If I buy a building, I get the blueprints, the engineer's sign offs and 
dates, I get a LOT of information about how that building was built, to 
what standards, etc.  I get another sign off from a professional 
engineer at a government agency that the building meets current 
standards, and most importantly...

If that building does fall down, I have a lot of documentation of who's 
PERSONALLY involved with their NAME on the thing.

Shouldn't software engineers be that liable (and probably also 
compensated better at the high-end of their skill levels)?

Doctors, Lawyers, other Engineering disciplines, Architects, they all 
have HUGE levels of PERSONAL liability (and motivation!) on the things 
they work on.  Somehow Software "engineering" has managed to not have 
that.  You don't see many software engineers contemplating taking out 
personal liability insurance to cover them in case their employer 
subrogates against them.

I think software engineering's relative anonymity probably hurts the 
overall quality of the output.  If your name and a signature that you 
claim it does everything it's supposed to, had to be on it when it 
shipped, would you ship it yet?

If someone buys a multi-hundred-thousand dollar software package to 
handle some huge portion of their business -- they get nothing but a 
disc and the thing still might be so difficult to integrate that they 
have to hire an army of consultants.  Especially egregious in this 
regard, are any software packages labeled "Enterprise".

(In most cases, all that label really means is that you're going to have 
to hire a crew the size of the Star Trek Enterprise to install, 
integrate, operate and maintain it.  And that the sales guy who sold it 
to you just started receiving juicy commission checks for the rest of 
his natural born life.)

It's also more likely they'll get told "that's a trade secret", if they 
ask for more detail of how the software was actually built, even after 
the purchase is completed and maybe even with an NDA in place.

The more expensive the software is, the more likely you can't get any 
information about it at all.

Open-source gets someone the code, but that's not enough -- it doesn't 
get them the design, the architecture, and the philosophy of the 
Architect and Engineer working together.  A completely different 
talented team of people who "build software" could review it for you, 
but you just paid someone to do that when they built it in the first 
place.  They still owe you information about how they built it, but 
you'll never see it.

> 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.)

Sure would be interesting.

> 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.

Agreed!  Great example!  :-)

Nate