Software engineering Re: [Beowulf] Stroustrup regarding multicore

[Gerry Creager]

Lux, James P wrote:
> 
> 
> 
> On 9/3/08 7:31 AM, "stephen mulcahy" <smulcahy at aplpi.com> wrote:
> 
> 
> 
>     Perry E. Metzger wrote:
>     >  How it is possible that people managed to read that much and hear
>     >  exactly the inverse of my central thesis, I don't understand at
>     >  all. Perhaps everyone just hears what they want to.
> 
>     Sheesh, I resisted for a long time but ....
> 
>     The scenario above pretty much sums up the situation I see with one of
>     the softer sides of software engineering - the requirements gathering,
>     which I'd see as fundamental to a successful (software, or indeed
>     general IT project). IMHO, the most important part of most projects is
>     figuring out what the heck the "stakeholder"[1] wants in the first
>     place.
> 
>     --- And that’s assuming the stakeholder really understands what they
>     want.. Often it evolves as understanding improves (this is one of
>     the arguments for RAD and XP).

Rule 1: Never let an oceanographer with 2 FORTRAN courses design or 
maintain any software project with more than 16 lines of code checked 
into the repository.

Rule 2:  Oceanographers with less than 2 formal FORTRAN classes have 
decided they're really nacent software engineers because they've 
mastered most of the buzzwords, and thus will give you all sorts of 
"requirements" which are typically orthogonal to any software design or 
engineering training you've had.

Rule 3:  If you finally convince the denizens of Rule 2 that their 
application cannot be written as spec'd, they are suddenly experts in 
"Service Oriented Architecture" and Software as a Service.  And you're 
not.  So there.  Just believe me.  Really.  Cause I said so.

Don't ask me how learned these truths.  Oh, and the bar is slightly 
higher for meteorologists, by a couple of additional formal software 
classes.  But in the grand scheme of things, it's not much higher...

>     No matter how good your programming is, if your requirements are
>     wrong - you're heading in the wrong direction entirely (a bit like
>     building a really neat spacecraft and then launching it towards Pluto
>     instead of Mars[2]).

ibid.  Been there, done that.  But not for spacecraft.  Or, I could talk 
about computer scientists just now discovering what discipline experts 
do for the Data-Net NSF call that's out now, but that's another thread...

>     ----- All depends on the alignments of planets and stars..  I
>     wouldn’t go so far as to say things are planned using astrology, but
>     we (JPL) are probably one of the few businesses around that can use
>     the motions of heavenly bodies to predict our business base and
>     workforce requirements.  Every 26 months as Earth comes into trine
>     with Mars is an auspicious time for launch (you want to launch at a
>     time that is roughly half the trip length before closest approach)

Show-off :-)

>     This is SoftwareAnalysisAndDesign at beowulf.org right?
> 
> 
>     --- you betcha.. When it’s not HardwareAnalysisAndDesign...
> 
>     Jim Lux
> 
> 
>     -stephen
> 
>     [1] Am I the only one that can't help using that word and visualing a
>     Van Helsing type waving a wooden stake around?

They're grasping it to keep me from driving it through their hearts... 
Oh, yeah.  That meeting is already over.

>     --- Cecil Adams of “The Straight Dope” says that wooden stakes only
>     work on some kinds of beasts. It’s apparently a geographic thing..
>     Other places you need silver bullets, garlic, or something else.

My personal preference is a garlic-flavored wooden stake.  I keep the 
silver bullets for backup when I missed with the stake.
-- 
Gerry Creager -- gerry.creager at tamu.edu
Texas Mesonet -- AATLT, Texas A&M University
Cell: 979.229.5301 Office: 979.862.3982 FAX: 979.862.3983
Office: 1700 Research Parkway Ste 160, TAMU, College Station, TX 77843