Client Relations

When working on an application for a client, it’s important to consider the long term—ideally, you want to keep a good client for many years to come, so it’s worthwhile to make a few changes or add a new feature the client isn’t sure about, free of charge, as a gesture of goodwill. Needless to say, there is a balance here. Doing work for free makes sense as an investment of your time in exchange for goodwill when dealing with a reasonable client who will probably be paying you for work for many years to come and recommending you to other potential clients. But if you make changes or add features to an application free of charge for a client who just wants the maximum work done for the minimum charge and who will take advantage of your consideration to ask for more and more changes free of charge, this can become a very bad situation.

I don’t know if I can tell you how to accurately classify clients, other than just by proceeding cautiously and observing how a client reacts to common situations such as an application needing some tweaking after delivery. As always, the best predictor for future behavior is past behavior—a client who complains vociferously about having to pay for new features he requested after the application was created according to his original specifications, and pays late, is probably going to continue to behave in the same way in the future.

After working with a client for a while, you will generally have a good idea whether you and the client tend to think alike about possible database features and changes. If you find that a particular client generally approves of changes you think are needed, you can feel comfortable with just going ahead and making any changes that seem to be called for without prior approval. Other clients may see things differently from you, so when doing work for them and because you can’t predict what they would like based on your own preferences, if you realize that another change might be needed, while working on something else, it’s best to check in advance before making any changes that haven’t been specifically requested by the client.

One situation that comes up from time to time is a client request that you know is not appropriate—either it just won’t work or it will lead to serious problems elsewhere in the application or it just isn’t the best way to do something. For example, the client might want to have three phone number fields in the Customers table, to store work, home, and fax numbers.

You can just tell the client, “that won’t work,” or something similar, and provide a technical explanation of why this violates the first normal form, but that is rarely a good idea. The client will feel insulted, and probably won’t understand the explanation in any case. In these cases, when feasible, I generally say something like, “I can do that, but there are a few other alternatives you might also want to consider,” and perhaps do a demo of the alternatives (in this case, having the phone numbers in a separate linked table).

Ask the client to consider the case of entering a customer’s cell phone number. Hopefully, the limitations of having three fixed fields in tblCustomers will now become apparent (there is no Cell Phone field!), and the client will see the benefits of putting phone numbers into a separate table—without the need for an insulting lecture from you. At this point, several things can happen: (1) The client goes along with the more reasonable alternative; (2) the client provides a good reason for having a non-normalized table (say, meeting very specific government requirements based on outdated database technology); (3) the client will insist on having the three separate phone fields, without any good reason. (1) and (2) you can work with; but (3) will clue you in that this is an unreasonable client who will probably be difficult to work with in the future.