Chapter Fifteen: A Blueprint for Savvy Programming

A user for whom you are designing a system can be your best advocate or your worst nightmare. Even difficult or reluctant users can be brought around if the programmer is courteous and respectful. Determining the end user s needs, along with the project specs , is the first step in this five-step blueprint for savvy programming.

One of the ways you can prove yourself valuable to your company and to your manager is to be able to take on tasks beyond coding. Most programmers can take well-written specifications from a manager or a systems analyst and write code to match those specifications. The next step beyond being simply a journeyman programmer is to become good at developing specifications from user and management input. In this chapter, I ll go through the steps you must master before you re ready to advance in your career.

Step 1: Get the Project Specifications

If you usually get your specifications from your manager or a systems analyst, going to the end user may be a big step for you, but it s an important skill to learn. When there s no systems analyst on the project, you will have to go directly to the user and get the specs, normally starting with the output report or desired screen or function that the user wants. Then you work that back through the input that s required ”perhaps disk files, or whatever ”and then the data that the user might have to enter online.

You gather all this into programming specifications ”either for a new program (perhaps a new application or a new online function) or for the maintenance of an existing function.

Sound easy? It isn t too difficult if you have a user who is able to clearly identify and communicate his requirements. But that is not always the case. After you ve worked with a user for a while, you ll be able to gauge the quality of his requests ”which are savvy, which are not well thought out, which are frivolous. You ll know, with experience, which users have done their homework and focused intelligently on the problem. It s a pleasure to work with savvy users. But you must be able to work with all users, and it is your job to lead them to the correct solution. You cannot let the user dominate in IT areas in which you are more qualified than he is.

So you must take the user s request, clarify it, and try to understand it. Then you should go back to the user and have a dialog to make sure that his request is legitimate , that you can do it, that the results will be satisfactory to the user. Your job is to see through the user s request, to focus on what the real problem is, to come up with the correct solution to that problem, and to lead the user to accept your definition of the proper solution.

The more savvy and experienced a programmer is, the fewer specs he needs, but if the request is for a change to an existing display screen or printed report, I expect a picture of the screen or report with the requested changes clearly identified. Printers have always insisted on specific, numbered changes to a business form, for very good reason ”because that is the only clear way to identify and freeze the changes. After you ve done similar programming functions, and when you have enough experience to understand the business functions or applications, you won t need much in terms of formal specs. You might need only a sketch of the newly requested output or a conversation with an end user to determine readily a very good way to do that application.

If the request is for a core business function that you already know, you can be very helpful to the end user in refining his request. Indeed, you can fill in the details and come up with a much more elegant and useful function than most users could dream of. Once you ve done that, the user will learn to rely on your work and request that you do more work for him.