Off Topic: Programming woes. Was: Response to a slide

[David McFarlane]

Greg,

Amen!!


At 2/26/2009 09:07 PM Thursday, you wrote:
>Warning:  Continued rant
>
>Agreed.  A lot of the problem that I have noticed in my career, (not 
>referring specifically to this project, my current position is as a 
>consultant for industrial data acquisition and testing software and 
>hardware), is that non-programmers simply do not understand what is 
>involved in creating a good piece of software.  A lot of people look 
>at computers and see how they make everything easy and fast for them 
>and assume that the programming part must be easy and fast as 
>well.  (Would you like your project quickly, cheap, or done 
>well?  Pick two :) )  People see the front end on a piece of 
>software which is abstracted out to the point of it having a very 
>simple look and feel and is easy to use and figure that what is 
>going on in the background is the same, fairly simple.  However, as 
>you probably know, the simpler you make a program to run and use, 
>the more complex it is.  Attacking something like a complex piece of 
>software without first building up a plan, assembling detailed 
>documentation, and clearly defining the specifications is a recipie 
>for a disasterious project.  The kind of projects I typically work 
>on are on the order of a few hundered hours of work and billed at 
>$120-$135 an hour, so having a plan is very important.  It also 
>means that I need to sell my customers on the fact that I can give 
>them something that is done right, the first time, that is modular 
>and expandable and works with very few bugs (nothing is ever 100% 
>bug frre except for "hello world" programs).  If someone is going to 
>pay tens of thousands of dollars for a bit of custom software, you 
>deffinatly do not want to give them something you banged out in a 
>weekend.  If you are not able to do it right, a lot of times it's 
>not worth the headache of doing it at all.  There is nothing worse 
>than agreeing to do a project on an accelerated time table and 
>cutting corners and them coming back to you latter and saying "there 
>are bugs, we need you to fix them and we do not think we should have 
>to pay for it because you supplied us with buggy software" when it 
>is buggy in the first place because of how they emanded that it be 
>done up front.
>
>On Thu, Feb 26, 2009 at 5:16 PM, David McFarlane 
><<mailto:mcfarla9 at msu.edu>mcfarla9 at msu.edu> wrote:
>
>Greg,
>
> >I only had the few minutes to get it set up
>
><unsolicited-editorial-rant>
>That illustrates the bigger problem here.  Behavioral research labs
>today seem to think that they can do research in a rush, and so do
>not allow time to do things properly.  Back in my graduate training
>in the early 1980s, my advisor at the University of Chicago actually
>reminded me that science is a deliberative process, and I needed to
>slow down and take more time to ponder things.  Seems our culture has
>abandoned those values, taking an abundance of whiz-bang technology
>as a substitute for timely deliberation.  As for me, I do not find
>that an improvement.  But then I am a cranky old geezer.
></unsolicited-editorial-rant>
>
>-- David McFarlane, Professional Faultfinder


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-prime at googlegroups.com
To unsubscribe from this group, send email to e-prime+unsubscribe at googlegroups.com
For more options, visit this group at http://groups.google.com/group/e-prime?hl=en
-~----------~----~----~----~------~----~------~--~---