Documenting a Access Application for Developers [closed]

Question

I need to document a MS-Access application that was created, developed and maintained completely by a power-user over 10 years.

This is an interesting situation because what they want is a manual so that a future developer can come in without prior domain knowledge and make changes to the frontend or the backend in a timely manner.

There are a few questions on my mind for this little project:

• What is a good manual design creating application? Microsoft Word doesn't quite cut it.
• What kind of things would you, the developer, need to know in order to make changes to things like forms, reports, tables or other Access objects?
• Anything else I missed? Any pitfalls?

Answer 1

In my experience, Access and VB6- based programs are plagued by more code replication and technical debt than programs in mainstream languages. I'm not sure why. Maybe it's the nature of Access as a "prototype" or "toy" database (though it can be quite powerful when yielded correctly).

If I had to choose between expending time on documentation and expending time on reducing technical debt, for example by remodularizing, eliminating repeated code, splitting long functions, etc., I would choose the latter. The improvement to maintainability and readability would be greater.

Answer 2

You could start with generating some automatic code documentation using MZ-Tools add-in for VBA. The same add-in can help you clean unused variable declarations, generate line numbers, reorder procedures within a module, etc.

Documenting forms is more difficult. My proposal would be to keep a screen shot, alltogether with a .txt file obtained through the undocumented application.saveAstext method.

Answer 3

I know this is closed for long, but I can't refrain adding my 2 cents:
In the case mentionned, I think the most usefull doc to produce is a FUNCTIONAL documentation (which should have existed before starting the development in an ideal world).
Second is within the code itself, and that includes the VBA but also the field descriptions which can be set in Access and SQL Server.
Third is a (or a set of) nice database diagram. Once you have that, all the rest can be generated by the new developer using HIS favorite tools.
Speaking about tools, I particularly like and recommend:

• MZ Tools: specially to easily find which routines call the one your looking at
• Smart Indent: to properly indent code. Trying to read badly indented code makes me sick
• SqlSpec: (not free) generates HTML doc of the database itself for most database engines

Answer 4

Have you tried the using the built in database documenter? It will print out all tables, indexes, forms, controls, each property of controls. Code, the sql used and just about any thing else. This results in huge, but just massive printouts. However, while it will kill a few trees in the process it sure is a great way to impress the boss.