- The Need for Design
- User-Programmer Agreement
- Steps to Design
- Summary
- Workshop
This chapter is from the book
This chapter is from the book
This chapter is from the book
User-Programmer Agreement
Suppose you accept a job as a programmer for a small business that wants to improve its Web site. (After you've gone through these 24 hours, you'll understand programming better and you'll even learn how to write Web programs in Java.) The Web site changes that the owners want sound simple. They want you to write some interactive Java routines that enable their users to look at an online inventory and to print order lists that the users can bring into the store for purchases.
So, you listen to what they want, you agree to a price for your services, you get an advance payment, you gather the existing Web page files, and you go to your home office for a few days. After some grueling days of work you bring your masterpiece Web pages back to show the owners.
"Looks good," they say. "But where is the credit card processing area? Where can the user go to order our products online? Why don't you show the products we've back-ordered and that are unavailable? Why haven't you computed sales tax anywhere?"
You've just learned a painful lesson about user-programmer agreements. The users did a lousy job at explaining what they wanted. In fairness to them, you didn't do a great job at pulling out of them what they needed. Both of you thought you knew what you were supposed to do, and neither knew in reality. You realize that the price you quoted them originally will pay for about 10% of the work this project requires.
Before you start a job and before you price a job, you must know what your users want. Learning this is part of the program design experience. You need to know every detail before you'll be able to price your service accurately and before you'll be able to make customers happy.
NOTE
Proper user-programmer agreement is vital for all areas of programming, not just for contract programmers. If you work for a corporation as a programmer, you also will need to have detailed specifications before you can begin your work. Other corporate users who will use the system must sign off on what they want so that everybody knows up front what is expected. If the user comes back to you later and asks why you didn't include a feature, you will be able to answer, "Because we never discussed that feature. You approved specifications that never mentioned that feature."
The program maintenance that takes place after the program is written, tested, and distributed is one of the most time-consuming aspects of the programming process. Programs are continually updated to reflect new user needs. Sometimes, if the program is not designed properly before it is written, the user will not want the program until it does exactly what the user wants it to do.
Computer consultants learn early to get the user's acceptance, and even the user's signature, on a program's design before the programming begins. If both the user and the programmers agree on what to do, there is little room for argument when the final program is presented. Company resources are limited; there is no time to add something later that should have been in the system all along.