[lug] software engineering

[Michael J. Hammel]

I've been following your arguments, Nate.  While I agree with the basic
premise that not enough testing is done (in general), you're arguments
about software engineering don't really hold up (IMHO, of course).
Comments follow.

On Mon, 2006-11-13 at 13:21 -0700, Nate Duehr wrote:
> Every Joe on the street knows what a "computer software crash" is, and 
> how millions of dollars is lost a year to them.  (Billions?)

Millions or billions, as defined by who?  Ask the Joe on the street
where that number comes from:  the media.  The number is a perceived
value in lost productive time, something that is not actually
measurable, just estimated.  And usually estimated badly.  How
unproductive is Joe Schmoe when Word crashes, considering he was
probably surfing the net before he finally got around to using Word in
the first place.

Or are we talking about only a select group of individuals who are
actually impacted by downtime?  How do you categorize who is in and who
is out of this group?

> But you rarely hear about "building crash"... ya know?  They're not 
> falling down so often that people notice it, anyway.

Chances are you hear about nearly *every* building collapse, but not
every software crash.  Why do you think that is?  Apples to apples?
Hardly.  The last building crash I heard of killed a lot more people
than the last software crash (even the worst software crash).

> The thing is... re-use of concepts is heavily used in building 
> buildings, and formalized job roles are in place -- Architects, 
> Engineers, Construction Supervisors, Workers of all sorts, they all know 
> their piece of the job very well.

All?  You overestimate the average <fill-in-the-blank> engineer.  How
many "construction engineers" are employed to build houses, and how many
of those homes have serious flaws?  Do you really think none of them do?
Only a few?

> Software companies, even big ones, typically still don't quite have that 
> level of consciousness about code.

No, they don't.  But I think you overestimate the rest of the
engineering world.  And again, you're comparing the average throw away
piece of software only with construction that could be life threatening.
It's not a meaningful comparison.

> The knowledge re-use in building structures is formalized to the point 
> where its put into Building Codes.

Which these engineers follow to the letter, bar none.  Is this your
premise?

> Software has almost no such correlation, and is far more immature (both 
> from a number of years standpoint, and also from an attitude standpoint 
> of many developers) in this regard.

Software is immature.  The tools of the trade are still far from the
tools used for construction.  Even electrical engineering is far from
that maturity.

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

Software that needs to be right the first time is just as critically
examined as work to build a bridge on which many people will place their
lives.  Software that isn't critically examined is better compared to
the shed in the backyard, which is also not crtically examined.  How
many sheds fall in that we don't hear about?  Why?  Because it's not as
important as the bridge.  How much life-critical software fails that you
hear about?  Not desktop crashes.  Not bank's being hijacked.  But "the
building falling in" type software failures.  How many?

> When 40% of CxO's say their biggest problem is "software that didn't 
> deliver what was promised", that's enlightening, isn't it?

Who made the promises?  My experience has been that it is *not* the
software engineer who makes those promises.  It is another set of
professions entirely that is responsible for that problem. 

> Software simply doesn't go through anything close to this level of 
> testing or anything many orders of magnitude close to it.

I think you need to examine the software policies of places like the
Shuttle program or nuclear reactors or submarines or....

If you're trying to compare test pilot testing of flight systems to
desktop office applications, you're not really comparing reasonably
identical systems.

> > The discipline is there, when it is needed and cost effective.
> 
> It's ALWAYS needed, so cost effectiveness is really the driver.  :-) 

Always?  Really?  Just like it's always needed when putting up that
shed?  Or building the dog's house?  Or putting up a fence around the
yard?  There is such a thing as "over-engineering".

> How many software shops do you know that ask the engineers to look at 
> ways to create code more inexpensively?  I've never heard that question 
> asked of a developer ever in the business world.

You're kidding, right?  That's the *only* question they ask.  Better.
Faster.  Cheaper.  I think I'm missing what you're trying to say with
this comment.

> The whole sales cycle is 
> economically built to force instability.  

This is true for commericial, COTS type software, especially desktop
software.  But this has nothing to do with software engineering
practices.  It has to do with sales and marketing issues.  Saying this
is a problem with software engineering is like saying the Corps of
Engineers is to blame for New Orleans leaking instead of blaming
congress.  Congress not allocating the funding for the problem doesn't
make the members of the Corps of Engineers any less engineers.

> Most coders out there are probably 
> spending 50% or more of their time re-writing the same string 
> manipulation code they wrote the day they joined the company, on the 
> shiny new platform, be that a new OS, or a new OS and new hardware, etc.

Prove that.  Don't make up numbers.  And if you want try the comparison
game again, imagine if building designers had to work with windows whose
shape was never known before hand.  String manipulation changes from
application to application.  At the application level, few people
rewrite strcpy().  They write wrappers around it for
application-specific needs.  Just like construction engineers don't plan
for the use of shims on windows.  You use it because a specific
application requires it.

> Scripts are never uploaded to production systems without peer and 
> Engineering review, and are never added during the Production day.  Root 
> access is never allowed unless something is seriously broken during the 
> production day, and every single command that's going to be typed into 
> the machine at the shell prompt is written down in a formal 
> Method-Of-Procedure (MOP) document and reviewed and tested on a lab 
> system before done in production.  Even a simple, "We'd like to remove 
> the excess junk in /tmp" requires a written document of exactly what 
> you'd type to do it.

[..other stuff removed..]

This isn't necessarily engineering discipline.  It's formalized process.
Lack of process control is a problem in most companies.  People don't
like long lines and lots of paperwork.  That's a human problem.  But
it's not a reflection strictly on software engineering.
-- 
Michael J. Hammel                                    Senior Software Engineer
mjhammel at graphics-muse.org                           http://graphics-muse.org
------------------------------------------------------------------------------
            What I have to say about this book can be found inside 
                        the book.  --  Albert Einstein