- The Need for Design
- User-Programmer Agreement
- Steps to Design
- Summary
- Q and A
- 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 create sales and inventory software. (After you’ve gone through these 24 hours, you’ll understand programming better, and you’ll even learn how to write programs in Python or be able to switch to another language.) The changes that the owners want sound simple. They want you to write some interactive Python routines that enable them to look at existing inventory and to print what products have sold in the past day, week, month, or year.
So, you listen to what they want, you agree to a price for your services, you get an advance payment, you plan out the software, and you go to your home office to begin the work. After some grueling months of work, you bring your masterpiece program back to show the owners.
“Looks good,” they say. “But where is the report that breaks down credit card versus cash purchases? Where can we check in-store versus warehouse inventory? Where does the program list the products we’ve back-ordered and that are unavailable? Why can’t the program total sales tax we’ve collected 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.
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.