The customer will not be satisfied unless you service his needs. Often, he is unable to articulate what he really wants but will know it when he sees it. Some ways to get his wishes out and on the table are prototyping, discussion groups/brainstorming sessions and questionnaires. In each of these methods, you have to do your homework first because what you are really doing is presenting ideas and listening to the feedback and criticisms. Even if you haven’t the foggiest idea of how to really approach a problem, you need to start with something that seems plausible and let the customer know where you’re coming from. He’ll be more understanding if he knows you’re groping too.

If you still have trouble getting to the gist of the problem, try the ‘Swiss cheese’ approach of taking the problem apart into smaller pieces. Something like ‘If you could change just one thing, what would it be?’. Then follow that up with ‘Why would that be better?’. Now you know two things; something he wants and why. Try that a couple more times and he’ll start to open up with real issues.

When you think you are finished with the requirement search, you need a way to determine if you really understand the problem. Do that by creating your solution as a picture, a briefing, whatever media/format your customer would most understand. Your solution will be easy to understand and obvious as an appropriate answer to the need if you truly understand. That means you are ready to present it to the customer and go on to the next step. If it’s hard to understand or convoluted in its logic, you’re not done yet and you need to go back for more discussions.

In the rush to design and code to meet the usual deadlines we are tempted to just do what is necessary to solve the immediate problem. But this is a shortsighted approach that means you’ll be back in the code in the near future. The reason is simple. Things change! Since it is a lot cheaper to design flexibility in at the beginning than to retrofit later, do it now.

For example, try to look at things like this:

• Any choice that could ever have more than two values becomes a table
• Any small snippet of code that might ever be used again becomes a subroutine
• Any constant that could conceivably change becomes a variable
• If a set of data can possibly be viewed from more than one perspective provide for multiple choices

There are many reasons to keep it simple. You’ll have to go back into it two years from how. You turn the program over to someone else. Alzheimer’s is setting in! The customer has to understand it to approve it.

But perhaps even more important is that keeping it simple can help provide the flexibility to support tomorrow’s needs. Say you have a task made up of three main activities. You could design your solution as one monolithic piece of code. The result is relatively complex and inflexible to need change. Design it instead as three, interacting ‘mono-tasks’. Now each piece is much easier to understand because it deals with a single primary activity and you can easily trade out any one piece with new code to accommodate a change in requirements. Does this hearken back to ideas like code cohesion, information hiding, object oriented? You bet!

This one really comes from the days when computers weren’t as reliable. But it’s just as true today because we continue to make mistakes and so still do computers. I generally keep at least four copies of everything. Two copies, one original and one ZIP, on my working machine and another pair at the customer’s facility. For the really critical stuff, there’s another set on my server. The ZIP copy allows you to work on new code while maintaining a copy of the current production code. More than once, that third set of copies has saved me when, at the end of a major update, I found that something had gotten dropped on the floor.

I use Lap Link to maintain consistency between the various sets. The chief benefit of its use is the ability to copy only what has changed or is already present in the destination. So you can start up a backup operation and walk away to deal with other pressing matters, knowing only what needs to be copied will be copied. Visual Source Safe can be a big help here as well. Its only drawback is that there is no automatic update function. You have to diligently perform updates to maintain consistently across copies of the code. VSS’s big plus is that you can use it to highlight exactly what changed from version to version.

In the human interface arena, consistency helps your users because they know what to expect from application to application. It also means you’ll have to worry a little less about documentation because you always do a particular thing in a particular manner.

In your code, consistency helps both you and your colleagues. You and they will know just where to look to find things and how certain functions work. That means you/they get more work done and the newcomers require less training.

For applications meant to be operated by humans, the Registry is a fine place to store your parameters. But, a production program has no operator and, at most, one user. A production program may also need to serve many different sets of data.

Have you ever tried to edit the Registry on a remote machine? I don’t think it can be done. But an INI file can be placed on a network accessible drive and it can be viewed/edited with a simple editor. The application using your INI file can even sense when it changes and react accordingly.

I’ve taken the approach of making the INI file name the first command line argument for all programs so that there is commonality between them. If the file name is not stated, it’s the program name and it’s located in the program’s directory. But if the file name is stated, it can be anywhere. This approach allows the program to be used with a number of different INI files to solve different problems.

When building a component to be used by executables, either as a component or a separate DLL, the INI file may be tied either to the DLL name or to the using EXE depending on the using programmer’s choice. To determine what environment the code is running in, query App.StartMode. Its value is vbSModeAutomation if the code is running as a DLL and otherwise if not. Then be sure to provide a SetupINI method to give the using program the opportunity of controlling where the INI file is located and its name.

When using an INI file, I think it’s a good idea to always write the final settings back to the file. In this way, all the setting items are exposed to observation and no one has to guess what they are.

Actually, I mean Classes and Libraries. If you ever write the same set of lines more than once, it belongs in the Common Code category. The key issue here is re-use. But you also gain in simplicity and understandability in the code. It can also pay off big time when it comes to the testing phase. If you make heavy use of library materials that have already been fully tested and used in the production environment, you shouldn't have to re-test them.

At the very least, heavily comment your code. Use a formatter like that in VB Advantage to help make it easier to read.

Whether a user is present during execution or not, you need to be able to record what happens so can isolate and fix problems. If there is any user interaction in the program, the time required for writing the debug file will not be noticed. Or if the program is a pure number cruncher, limit the amount of debug to just that of real value.

Of course, you will be tempted to turn off the debugging once you go into production but I suggest you don’t. Of course, if you don’t turn it off (it is controlled in the INI file isn’t it?), the users will anyway. That being the case, what you really want to do is always collect debugging information retaining say the last 5-10K bytes of it to be printed, saved to a file or automatically mailed to you if a problem shows up.

You can’t allow a production program to display the dreaded Message Box because there is no one home to answer it. Provide an error handler in every situation where an error can occur, build a message containing all the particulars, put it in the log, and go on with business. If it’s a serious error, send a message to somebody in operations so they can look into the problem.

If you do insist on displaying a Message Box, because someone might walk by and see it, make it a timed message. To do this, establish a known title for it, start a timer that will tick when it’s time to take the message down and then use the following code to close the Message Box when the timer ticks:

Don’t forget to include the Declare statements for FindWindow and SendMessage.

A production program is meant to be run all by itself with no one around to hold its hand. All too often we see programs that absolutely require human intervention to complete their work. This probably happens because the programmer can’t see how it can be done without his help. Job security and that sort of thing. This approach works fine until the first time you’re not available and the boss starts asking why it doesn’t work.

Since you sometimes need to watch it run (while controlling it very tightly), you will probably need to build a human interface to support that. Just be sure there is a way to let it do the job by itself.

I don’t mean casual testing. You need to learn how to be as fumble fingered as your users. And, somehow, you need to forget how to use the program. One approach that works pretty well, providing all your subroutines are reasonably single-purpose, is to construct a check list of all subroutines in your project. You can automate the construction of the check list by realizing that each VB subroutine starts with one of these 12 possible strings (Public Function, Private Function, Function, Public Sub, Private Sub, Sub, Public Property Get, Private Property Get, Property Get, Public Property Let, Private Property Let, Property Let) and create a small program to create the list.

If you can con your friendliest computerphobic into helping you, go for it! You’ll get a valuable lesson on what everyone doesn’t know that ought to help you in the future. If you think this is far out, consider that there are users who find that "Windows for Dummies" is too advanced to understand.

© 2000, Verified Software Products Company