Visual Basic Programmer

Microsoft Access Database Programmer

Improving Access Database Systems

An existing Access database software system may not be able to cope with the growing administrative requirements of a company. The inadequacies may relate to increased volumes handled, additional functional requirements or new company directions.

A decision then needs to be made on how to improve the software to achieve the required quality and functionality. The choice is between two development options – Evolutionary development or Revolutionary development.

Here is a brief summary of the differences between the two options:

Development by Evolution

This is the low risk choice – but not a glamorous choice. It involves adding small and frequent improvements to an existing system. It is a reliable and systematic means to improve an existing system. It could be thought of as an extension of the maintenance mode, but goes further than just fixing critical bugs.

The Benefits are:

• It is a low risk strategy.
• The cost of the strategy can be tightly controlled.
• It is always of value to build on proven work of the past.

The downside is:

• The system may be slow in showing results.
• The enhancements may be hard to implement due to the existing code.
• There may be technical limitations in the software that a step-by-step approach cannot resolve.

Development by Revolution

This is a high risk strategy – the failure rate of new projects is very high. So there should be sufficient incentive to go down this path. It involves completely rewriting the system using new and promising, but usually unproven technology.

The benefits are:

• Improving on antiquated coding techniques.
• Greater awareness of user requirements due to the known inadequacies of the existing system.
• New administration and management functionality.
• Incorporating the latest techniques and software technology.

The downside is:

• The old system and the new system must run in parallel until the new system is proven to be at least equal to the old system.
• There needs to be multiple attempts when converting the old system to the new. This is needed to allow the users to check the consistency between the two systems at each new release.
• Extracting the business rules from the code and the user interface may be near impossible.
• The new system may be unstable for a lengthy period.
• There may be resistance from the users.
• Success depends upon the quality of the new development team. If they are lacking in experience or foresight or competence, the project is doomed from the start.
• Despite all the advances in system design and development tools, the complexity of new systems remains. The success rate for new projects is low.
• An unsuccessful project could have a negative impact on the administration processes.
• An unsuccessful project could affect the viability of the company.
• If development is started from scratch, a valuable and costly asset will be thrown away.

Gathering Application Requirements

In most cases the original specifications are nonexistent, as are their authors. Where the original specifications are available, they will almost always be out of date, with the successive changes over the years. If the analyst is unable to extract information from the old system code (and this is usually the case), there is nothing left but to try understand the business processes from esoteric code, low level users and ill-informed managers.

To develop a software package, the analyst must identify the needs of the company. This is difficult as the analyst is unlikely to understand fully the company's work practices, or the terminology of the company. There is also the likelihood that management and the users do not know exactly what is required.

Extending the life of the system

Many books have been written about the development of new computer projects, so I will stick to ideas to improve existing software.

The Evolutionary improvements should:

• Improve the quality of the system, by adding error handling routines to each and every procedure. When an error is trapped, all possible clues should be extracted to help identify and solve the problem.
• Make the system more user-friendly.
• Create reusable modules for repeatedly duplicated code
• Simplify convoluted and spaghetti code
• Gradually replace system functionality with newer technology
• Use refactoring of the code to extend the system life span. This will improve the readability of the code, remove dead code, make the code easier to comprehend and maintain.

If the decision is made to try this option, and it turns out to be not feasible – little will have been lost.

Professional advice

A word of caution. Many programmers and consultants will go for the system rewrite option with new software and new technology. It is more fulfilling and improves their future prospects – it is in their vested interests to go for this option.

A word on upgrading Microsoft Access software

Newly released Microsoft Access software versions soon become dominant. It is then virtually impossible to purchase the previous version – and a database system could soon be using obsolete software.

There is always good reason to use the latest Microsoft software, not only because of the additional functionality, but also to avoid security issues and problems with procedures that no longer work on newer Windows operating systems. There is equally good reason not to use the latest software too soon. The best option is to wait until a few service packs have been released to ensure the best chance of a problem free upgrade.

Ignoring successive new Microsoft Access Database version updates is false economy. Sooner or later your Microsoft Access application will have to be replaced or the Microsoft software upgraded by multiple versions. Either way, this will be costly. The skills required for upgrades are soon forgotten.