Specifying a database

Our clients come from a range of backgrounds and we have received many different styles of specification. Some are more helpful than others. If you're a database user then the following hints might help you when you specify your next database. If you're a database developer then they'll help you be more helpful to your client:

Use the language of your workplace, don’t use technical terms.
Say what you want to achieve, not how you want to achieve it.
Concentrate on what information you need to get out of the system, don't specify the size and type of the database fields.
Don’t tell the experts how to do their own job and don’t get bogged down in the details.

The best specifications are simple ones. Give your database developers a simple request and they will be able to deliver it in a matter of a few days. You can then use this simple system for a while before you decide on the next move. The 'giant leap' method of specifying the whole system in minute detail only works where there are large teams on both sides who have plenty of spare time to argue over the contractual implications of every detail.

If database development can proceed in smaller steps then your developer can work with you to make sure that each step is sound before making the next one.

A useful analogy

We have just paid a plumber and his assistant several thousand pounds to refit our central heating system. I trained as an engineer and am quite capable of cutting and bending pipes and soldering them together but I was persuaded to call in the experts for this job. That was a good decision because this pair did the job well and were finished in less than a week. It would have taken me a month of weekends.

We did not specify the location of the radiators beforehand because the plumber needed to see how the existing pipes had been run before he could tell us the best place for the radiators. If we had given strict instructions then the system would have cost us even more money.

Whilst they were working I stayed out of their way. If they wanted a decision like 'Where would you like this radiator?' then I gave them a quick answer and went back to the office without offering any more advice. Telling them how to do their job would have upset them and they would not have been as cooperative or helpful.

Treat your database developer like we treated our plumbers:

Tell them what you want.
Keep out of their way.
Inspect their work afterwards.

But please don't tell them how to do it.

The Site Search feature requires JavaScript. If your browser does not support Javascript then please use our Site Map instead.

Hints & tips

The textbox class in Visual FoxPro 9 has a new Autocomplete property which shows the user the previous values that have been entered in that textbox.
Autocomplete in VFP 9

Your Access database will look more impressive if you add custom toolbars...
Custom toolbars

FoxPro has always had functions to read and write files at a low level...
Foxpro low level file functions

More...
More pages of hints and tips for users of Microsoft FoxPro and Access databases.

Site Map