[plt-scheme] Perplexed Programmers

I am an engineer that questions the notion that engineering is a more  
rigorous discipline than programming.  Engineering typically involves  
incremental changes while software development often heeds the famous  
Monty Python phrase, "And now for something completely different."   
Aircraft and cars are examples of this; manufacturers gradually  
change subsystems in a way that is hardly noticeable.  Meanwhile, the  
software world tries to write obviously better programs from  
scratch... like payroll systems.

I wonder why programmers like to claim how easy a task is and how  
little it will cost.  On the other hand, engineers seem to enjoy  
bragging about how *hard* a task is and how *much* it will cost.    
(These rituals occur, for some reason, after contracts are won.)

This means: an establishment can find programmers to provide the  
production estimates that are needed to justify pursuing a project.   
(e.g.: "It's easy, so we programmers can do it; it's cheap because it  
will be done tomorrow.") Unfortunately, programmers that conveniently  
provide the desired (yet totally misleading) information are not  
likely to be influenced by efforts of academia (or even the clergy.)

The above claim, which is too expensive to verify, is of interest to  
me because it seems that the absurdly optimistic programmers are  
'trashing' the software profession by acting as agents for leaders  
who are 'trashing' their professions.  In the payroll debacle, 12M$  
was first spent discovering that the problem is hard.  At that point,  
the movers-and-shakers should have concluded that the payroll system  
is so complicated that only huge amounts of money would have a hope  
of producing software to accommodate it.  Their decisions should have  
then included overhauling the payroll methods before a single line of  
code was written.

I argue that the first role of computer scientists in these cases is  
to convince leaders that established, rigorous strategies exist for  
developing data processing systems... and that these strategies are  
wasted if they are applied to disorganized activities.  Much of the  
discussion here has covered another role of computer scientists:  
developing programming practices for ensuring that the strategies are  
successful.  Please save me further embarrassment if I am wrong about  
these points.

In other words, the notion of Perplexed Programmers in this project  
is absurd.  The leaders are trying to apply software development to  
something that isn't reasonably solvable with software.   
Alternatively, Todd is correct: stupidity explains everything.

rac


On Aug 29, 2007, at 7:38 PM, Shriram Krishnamurthi wrote:

> Your analogy is verbally clever, but I don't think it stands up.  VCs
> are by definition engaging in high-risk activity.  That's the
> (ad)"venture" part.  But one does not think of day-to-day engineering
> activities as being high-risk.  The average manager who comissions an
> engineering artifact -- whether a factory shed, an engine for a plant,
> or a software application -- does not want to feel a frisson of
> excitement and sudder of fear as they do so.  These are just meant to
> be enablers toward some bigger end.
>
> By the way, I think there are ways in which software is far ahead of
> the engineering competition.  When you build a house, it does not come
> with several built-in monitors and indices that you can use to easily
> tell why it collapsed (if it unfortunately did so), as opposed to
> having to reconstruct why painfully and via sophisticated forensics.
> But computer scientists have realized that they can and should build
> the equivalent of "flight safety recorders", and several such things
> are now routinely built into software.  Even DrScheme, which is not
> especially sophisticated in this regard, gathers a good deal of useful
> (but not personal!) data when you submit a bug report to provide
> context for the problem.  This kind of introspective construction is
> now considered standard good practice in software, but is hardly the
> norm in physical engineering.
>
> Shriram
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme