Lack of Documentation

Lack of documentation is very common; and is seen even in medium to large teams. For the small teams; it is understandable; you usually don’t have enough resources (human, time, finance) and to cover this; here are few suggestions

Requirement Gathering & Analysis

Create a mailing list for the project and make your team part of it. Discuss your requirement over emails/threads; and assign one person to send a periodic email/post summarizing the discussions. The last such email/post will lead you to requirement specifications.

Project Plan

Ask your team to divide the project into components and give estimated dead line. Do this again on the email list. Once done; write the summary for every commitment; discuss it in a thread. The last such email will be your project plan. Rewrite this in a new email; and then keep posting the replies to this whenever there is any change in the plan. Each reply should contain up to date commitments.

Design / Implementation

I strongly recommend using Sharepoint or other such web enabled collaboration platform. Write your design/implementation documents there. On each deadline/milestone; take a snapshot of current versions of documents/artifacts; mentioned below

• Database

Use diagramming support of modern database engines; SQL Server supports this. Your diagram will be up to date always.

• Design

Encourage your team to use contract driven development; use interfaces (interface IFunctinoality {}). Your design artifacts can then easily be created using some round-trip modeling tools like Borland’s Together or Rational’s XDE

• Implementation

Encourage your team to at least mention WIKI/Sharepoint URLs in the comments. Modern IDEs (like Visual Studio) has built in browser and you can easily correlate code with the documentation.

Data Layer

Use approach of least access; in database access layer; keep separate logins for developer’s access (SQL Server’s Enterprise Manager / Query Analyzer) and your application access. The developer login can have full access to the database but the login being used for the application should have least access. This way seeing which objects the application login has access will leads you to dependency information. It’s also suggested to write auditing code in stored procedures; so that you can pin point “dormant objects” easily.

Middle Layer

Encourage your team to log method names, parameters being passed and backend (sql query or web service name/url) being used in each method. Such log file will lead you to the dependency information. Audit these log files; and to check bottle necks.

User Interface Layer

Use patterns like Model view presentation; the view interfaces will help you to keep things in control and reflect changes across user interface and middle layer easily. Counts of such interfaces will also help you estimate the size of your application.

More…

Use emails; encourage your team, not to leave the office/workplace unless a status of what has been done and what you will do the next day is informed to the project email list. The team lead should write periodic emails for “To Dos” and “Status” such emails will help you write status summaries for the management.

Also encourage your team to write postmortems on each milestone or on periodic basis. Let them write what they feel and wish. Keep such email threads separate; they will help you to improve your processes for the next project.