[lug] software engineering

[Michael J. Hammel]

On Mon, 2006-11-13 at 13:46 -0700, Nate Duehr wrote:
> 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.  

Bad analogy.  I know how much the materials cost for producing my
product:  servers, hard drives, even the cost per kilowatt hour for
electricity.  I can manage (if given authority) the contracts for any of
those.  That doesn't mean I know how much the product is priced at.
Neither do construction engineers know how much the building will sell
for. 

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

I don't buy that.  If the engineers are not involved it's because they
don't ask to be.  Few management types want responsibility for cost
centers.  It's always easier to pass the buck.  I've worked for >10
companies, from 6 person startups to Samsung and Dell.  This isn't a
software engineering problem, per se.  It's a human relations problem.

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

The same way you find out how much testing was done one the bolt you
just bought at Home Depot.  You contact the manufacturer and ask about
their testing process.  Some do it well.  Some, not so well.

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

Depends on where you live.  In parts of Texas (at least), you don't get
the blueprints.  

If you want to know what "standards" software was written to, well,
that's a whole different story.  Software vendors love to list
networking standards, user interface standards, language and operating
system standards, ad naseum.  Adhering to those standards is not
necessarily a sign of good engineering.  I worked with RLX in Houston
(the blade server guys, before they shutdown and sold their remnants to
HP) and they did a lot of WIGL or WICL or some other such non-sense
testing that said the product was "Microsoft compliant".  That's meeting
a standard with almost no value.

> I get another sign off from a professional 
> engineer at a government agency that the building meets current 
> standards, and most importantly...

If you're assuming that a gov't signoff ensures engineering quality,
well, I wish you luck (as I duck out of the way of the debris).

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

So what you want is not engineering displine, but legal recourse.  Big
difference.

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

We're already overcompensated.  Higher wages won't make testing more
prevalent.  Should we be liable?  Probably, for life-threatening issues.
Perhaps for some guarantees related to business practices.  But lets be
honest on that latter one.  If you didn't have the software and wrote
down the wrong things in your ledger, would the ledger manufacturer be
liable?  As with all things, lots of definitions need to be established
to make the liability meaningful.

> Doctors, Lawyers, other Engineering disciplines, Architects, they all 
> have HUGE levels of PERSONAL liability (and motivation!) on the things 
> they work on.  

And this guarantees they do the best job possible?  Like with OJ?  Even
with this so-called HUGE level of liability, we never hear of poor
medical care or walkways that collapse.  Right?

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

Employer?  You mean customer.  Liability insurance covers doctors and
lawyers from their unhappy customers, not from their employers.

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

No doubt.  This means that all software engineers are bad?  If a home
builder makes a bad tract of homes, then all contractors labeled "home
builders" are especially egregious and just another sign of how poor
engineering pervades the industry?

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

Again, this sounds less like a problem related to software engineering
and more towards business practices.

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

More business practices.  Software people tend to *love* to share what
they've done.  It's a personality trait (just look for software
engineers blogs and see what they talk about).  It requires non-software
people to put restraints on them.

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

Very possibly because many open source projects start out as someone
scratching an itch.  Then others with the same itch scratch harder.
This doesn't preclude a very well implemented scratch.

> A completely different 
> talented team of people who "build software" could review it for you, 

Peer review does happen on mission-critical software.  It doesn't happen
on desktop or, likely, in much enterprise software.  Should it?  Maybe.
Depends on how much I trust the reviewers.  If software engineering is
not a disciplined industry, who do you get to do the review?  A doctor?

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

As with blueprints, most people wouldn't know what to do with the design
anyway.  Just because *you* would, doesn't make it a value-add for the
industry as a whole.  The lack of an available blueprint does not
preclude the use of good engineering in the final product.  It does
reflect on business practices.  I think you mix business practices with
engineering too liberally.  
-- 
Michael J. Hammel                                    Senior Software Engineer
mjhammel at graphics-muse.org                           http://graphics-muse.org
------------------------------------------------------------------------------
Bumper Sticker: Don't like my driving? Then quit watching me.