Re: Is strong typing worth the cost?

[Gary Scott <scottg@flash.net>]

Marin David Condic wrote:
> 
> I have absolutely no argument with the notion that different problem domains
> are going to have different cost drivers. I believe I said somewhere else
> that if you didn't care about bugs and you didn't care about maintenance,
> then design work was just an up-front cost with little to no back end
> payoff. (With the caveat that if you do *no* design, your project might just
> fail entirely.)

Nearly everything I develop is likely to be categorized as Q&D code by
the those in this NG.  However, I think I produce fairly high quality
Q&D code.  I've done this by being highly "modular" and building up a
huge library of utility code that suits my typical problem domain
(avionics modeling and data analysis).  I can put together a Q&D
application (with GUI) very rapidly and still have 99% cross-platform
portable code, with all platform portability modifications located in
one or a few modules (i.e. packages).  So, I don't necessarily agree
with some that Q&D always means poor quality.  I'm not a programmer and
I've been asked to provide source to some of my tools on a number of
occasions to programming teams and have received occasional complements
on the structure, comment quality, etc.  I do not perform a formal
design process.  In fact for the last major tool, the team making the
request was not versed in software and had little idea what it needed to
do so I had to make it up as I went by dragging it out of them and an
avionic equipment vendor (verbal inputs and emails)...it seems to have
turned out well and cost 1/10 of what the subcontractor originally
estimated.

This wasn't intended to be a bragging session as I don't claim to be a
programmer (electronics engineer), just modifying the definition of
"Q&D" slightly.

> 
> One might reasonably ask: "Couldn't the animation software be well built and
> still do its job?" Is it of necessity spaghetti code? Is it somehow or other
> faster to get the job done to just start plodding along laying down code
> until the animation looks right? I suspect that if the hypothetical
> animation developers did *some* analysis and design up front and *did* build
> solid, reliable code that it would possibly not take any longer to get to
> market and might yield larger chunks of things that could be reused & save
> time/money on the next animation. (I wouldn't go to the extremes of analysis
> & design done for safety critical software, but surely the animator still
> needs to do some amount of "debugging" to get the thing to work at all and
> surely that means if there were better forthought and stronger checks, lots
> of those problems might be minimized.)
> 
> I see the point that throw-away code need not be well built. But it is not
> demonstrated that this is somehow faster or better or cheaper than
> well-built code to do the same thing.
> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> 
> "Darren New" <dnew@san.rr.com> wrote in message
> news:3CD0A3B8.7B7C8622@san.rr.com...
> >
> > On the other hand, if you're writing run-once software, it's pretty easy
> > to see that the cleanliness of the design is virtually irrelevant.
> > Consider software to animate a crowd of CGI characters in a movie. As
> > long as the end result looks good, it doesn't matter what the code looks
> > like. It could be the most god-awful mess of spaghetti code and misnamed
> > uncommented variables you can imagine, and it just doesn't matter. As
> > soon as the film is out, you're never going to run the program again.
> > Certainly if the requirement is "make the fur on the monster look
> > realistic", the first place to start is not the type system.
> >


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net