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

Greg Osenbach gosenbach at gmail.com
Fri Feb 27 02:07:28 UTC 2009


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.linguistlist.org/pipermail/eprime/attachments/20090226/059d137e/attachment.htm>


More information about the Eprime mailing list