Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Documentation

Status
Not open for further replies.

dwesnyc

Technical User
Nov 24, 2006
14
0
0
US
Hello. I've always used access by myself and consumers. Now I need to work with an additional access programer. The problem I am running into is how to document what we are doing and what things mean.

Does anyone know a good website that gives examples on how to work in a group with access so that everyone is on the same page?
 
In terms of documenting your system design this should all be done prior to the start of system build if you are working by the book. My preferred method is SSADM.

I'm not aware of any websites giving advice on working as a team of developers (although I'm sure they exist) however I have worked in small teams of developers on a few occasions in the past and have learnt the following through trial and error (a *lot* of error!):

Excellent communication is vital. The project will suffer significantly if your team contains even one developer who is prone to go off and do their own thing without regard to others. The best way of communicating is, in my experience, verbally with written records to cover you in case of unforseen absences.

Version control *everything*. Be *extremely* strict about this. Visual Sourcesafe works with MS Access (although not as effectively as with VB, C, etc). It may be worth considering the use of an application like this.

Have a nominated lead developer. This developer is responsible for releasing code for development and updating the master copy of the system.

Use classes and OO programming techniques as much as possible, without harming the design of the system. Agree the objects/classes and their interfaces in advance. Assign a single developer to develop each class. Do not deviate from the agreed interface design unless agreed with all other developers so that they can assess the impacts on their code. The one drawback to this is that SSADM doesn't really fit with OO design and development.

All code should be peer-reviewed before being updated into the master copy of the system. This ensures quality and a broader understanding of the system. You should never be in a situation where only one developer understands part of a system.

Code comments!

Good luck with your project. Working as part of a team of developers is very different from working on your own. You'll learn a lot, although it will be frustrating at times.

Ed Metcalfe.

Please do not feed the trolls.....
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top