Multi-Developer Issues

In this chapter, we are going to tackle the question of how Access functions in a multi-user environment. But we'll just take a moment to look at another multi- user aspect - how does Access work as a multi-developer product? So far, we have concentrated on the functionality that Access, DAO, and VBA provide for the user and developer but we have been considering these from quite an isolated viewpoint. To a large degree that is inevitable. After all, developing applications does tend to be a fairly personal experience. Sure, we may work in project teams and, yes, we may have weekly design meetings where we collaborate on various aspects of the design and development of the product we are working on, but when it comes down to the nitty-gritty of cutting code - most of us tend to work on our own.

Over the years there have been various formal attempts to get us all to program together (for example "peer review programming" where code is first written solo and then discussed and modified in groups or "extreme programming" where programmers take it in turns to write code with the others watching every move). None of these have yet been proven particularly successful.

I am not suggesting that the cubicle culture - familiar to anyone who reads Dilbert cartoons - is the ideal way to work, but a lot of the design and development process is a fairly cerebral process and lends itself to isolated, concentrated effort rather than a more communal approach.

To a large degree this has been exacerbated by the limited support that Access has traditionally offered for team development - Access was just not accepted or supported by Microsoft as a serious development language. Earlier versions of Access allowed multiple developers to make design changes to Access objects and code in the same open database but implemented it through a complex procedure behind the scenes that fooled Access into thinking that only one developer at a time was making those changes. Now that Access has matured and is being used for even major projects, industrial-strength source code tools such as Visual SourceSafe and Code Librarian, and full integration with Visual Studio have finally been made available by Microsoft. These do not ship with any of the standard versions of Access 2002 though - you will need the Microsoft Office XP Developer Edition. That is because Access 2002, in line with the other Office XP applications, does not allow multiple developers to make native design changes to Access objects and code in the same open database. So, if you want to develop in teams, you are going to need the Developer Edition.

The historical upshot of this approach is that many developers tend only to consider the multi-user aspects of their applications towards the end of the development and testing cycle. Even if they design their applications in teams, using the latest team development tools, many developers build their code alone. They also do their system testing alone and it is really only when user acceptance testing starts and two or three people use the database for real at the same time that multi-user problems start to show. Then, the application is rolled out in production to thirty users and it comes to a grinding halt. The developer says out loud "That's odd!", while they are really thinking "Oh <expletive deleted>!" and it is back to the drawing board, do not pass "Go" and do not collect $200...