Part IV: Professional Database Development
902
Overall, a well-written design specification provides the basis for creating tight, bulletproof appli-
cations that fulfill the user’s requirements. At the conclusion of the project, the finished database
can be compared to the design specification, and its effectiveness in addressing the original prob-
lem can be objectively evaluated. Without a design specification written at the beginning of a proj-
ect, you have no valid measure of how well the application resolves the problem that inspired the
project in the first place.Becoming one with documentation
Even the best-written Access application will fail if users don’t fully understand how to use it. And
it’s not just the user interface that needs to be understood: the logic of what happens when the user
clicks a particular button needs to be understood both by at least some of the users as well as by
any technical support staff who might be involved with the application.While many developers dislike writing documentation, leaving it as a last step that they hopefully
won’t have time for because they’ve moved onto another project, documentation really is a “neces-
sary evil.”Documenting the code you write
Over time, changes or additions might be required to the application. Even if you’re the one mak-
ing those changes, the passage of time since you originally wrote the code might mean that even
you have problems understanding exactly what the code does. Imagine how much harder it’ll be if
someone else has to figure it out!Include comments, use naming conventions, and provide logical names for your procedures and
variables. Don’t, for example, accept the default names that Access provides for database objects
such as forms and controls. The default names are simply a convenience for simple applications
and shouldn’t be used in professional-quality work.Figure 26.1 is an example of clear commenting and documenting. Imagine even this small section
of code without comments, and it’s easy to see how important documentation is.Cross-Reference
The chapters in Part II describe many valuable Access programming techniques.
Documenting the application
The applications you deliver to end users should be accompanied by printed documentation that
explains how the applications are meant to be used. End-user documentation doesn’t have to
include descriptions of the internal structure or logic behind the user interface. It should, however,
explain how the forms and reports work, describe things the users should avoid (for example,
changing existing data), and include printouts of sample reports. Use screenshots to illustrate the
documentation.