DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 3 of 3
  1. #1
    Join Date
    Jun 2004
    Houston area

    Do any of you have a problem with....

    users/management who tell you they want ONE thing and then change their minds ten different times before you're through?

    OR.........mangement that tells you they want something and think that you can just sit down at your computer and <POOF>! it's done?

    I've asked my management MANY times, specific questions that determine the way I've structured my MASTER database, which will create MANY (hundreds/thousands) other databases for global use. After MONTHS of work, they now tell me that they need it a different way!!


    Maybe they just didn't THINK about the answers to my questions when I asked them.


  2. #2
    Join Date
    Feb 2004
    Colton, CA
    I have this all the time. The most recent is this:

    A had to do a program to produce a calibration certificate. Some readings were taken from a database, some from a csv file. I had to draw boxes and lines on an A4 sheet and fill data. I couldn't use crystal reports due to all of the various data sources.

    So i made a template in word and got it approved by ALL managers. I then spent a week writing the program to read in and print the data, inlcuding all the .CurrentX and .CurrentY for printing.

    Once it's done, someone in marketing decided she wanted it to look like HER template so i was asked to do it again. I refused, but i'm sure it'll come back round in a few weeks and i'll have to do it

  3. #3
    Join Date
    Apr 2004
    New York City
    You're describing a breakdown in communication between Users and developers. It's a common scenario, where you get changes so late in the app that it causes all sorts of problems.

    The best solution I've found to this requires a lot more up front effort, but prevents most of the type of problems you're describing.

    What I do is create mock-ups of the program as I see it in my head; often to the point of supplying sample data. Then I let ALL the users who will be working with the app- or at least all the users who will be listened to by management when they have suggestions for "improving" the app- work with it. I do this as often as is practicable during the development phase- certainly after each major change/addition to the app.

    I find that users often can't verbalize what they want, until they see what they don't want on the screen! Users often don't understand what can be done in a program until they see it on the screen. Then they realize that one little change or addition can help them a lot in their jobs. Remember, these are Users, not programmers. We can't expect them to be application designers. The best way to elicit business needs from them is to give them a sample app & sample data to play with. This way you can get their suggestions/demands early enough in the development process to make the changes relatively painlessly. RHelliwell could possibly have avoided the problem menioned above by letting the User who requested the change see the app before the design was finalized. Sometimes just getting the Managers to sign off is not enough. Remember, the Managers are often not the ones who do the actual work with the app; they frequently have only a broad understanding of the day-to-day processes their underlings have to complete. If you let the underlings who actually do the work play with the sample app, you'll get much more useful feedback, and you'll get it soon enough to deal with it as painlesly as possible!:-)

    I'm sure we've all experienced the App From ****, aka the App That Wouldn't Die, which lived on and on as requirements were added so late in the game that each one caused a complete re-design and re-write. You can avoid this by letting the Users do their job of telling you what they need.

    This boils down to: involve the Users early & often. This may seem like more work up front, as I said, but it can often result in both less work at the end, and much more satisfied Users. Remember, ultimately our job is not programming- it's satisfying Users.

    Or, you can do without User input, suffer as you put in much more effort at the point where you thought you were finished, and ***** about it afterward. Some programmers seem to prefer this method. At least they'll always have something to complain about... ;-)

    Last edited by Andrew Cushen; 07-18-2004 at 03:17 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
HTML5 Development Center
Latest Articles
Questions? Contact us.
Web Development
Latest Tips
Open Source

   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center

We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.