Warning:  Continued rant<br><br>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.<br>
<br><div class="gmail_quote">On Thu, Feb 26, 2009 at 5:16 PM, David McFarlane <span dir="ltr"><<a href="mailto:mcfarla9@msu.edu">mcfarla9@msu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Greg,<br>
<div class="Ih2E3d"><br>
>I only had the few minutes to get it set up<br>
<br>
</div><unsolicited-editorial-rant><br>
That illustrates the bigger problem here.  Behavioral research labs<br>
today seem to think that they can do research in a rush, and so do<br>
not allow time to do things properly.  Back in my graduate training<br>
in the early 1980s, my advisor at the University of Chicago actually<br>
reminded me that science is a deliberative process, and I needed to<br>
slow down and take more time to ponder things.  Seems our culture has<br>
abandoned those values, taking an abundance of whiz-bang technology<br>
as a substitute for timely deliberation.  As for me, I do not find<br>
that an improvement.  But then I am a cranky old geezer.<br>
</unsolicited-editorial-rant><br>
<div><div></div><div class="Wj3C7c"><br>
-- David McFarlane, Professional Faultfinder<br>
<br>
<br>
<br>
</div></div></blockquote></div><br>
<br>
--~--~---------~--~----~------------~-------~--~----~<br>
You received this message because you are subscribed to the Google Groups "E-Prime" group. <br> To post to this group, send email to e-prime@googlegroups.com <br> To unsubscribe from this group, send email to e-prime+unsubscribe@googlegroups.com <br> For more options, visit this group at http://groups.google.com/group/e-prime?hl=en<br>
-~----------~----~----~----~------~----~------~--~---<br>
<br>