Everyone knows that as project size grows, so too does both the complexity and need for effective communications. Everyone also knows that as project size grows, so too does the overhead cost required to maintain and manage the infrastructure to support the project. The figure below qualitatively shows the industry accepted relationship between cost, complexity, and project size (based on the number of personnel allocated).

It is obvious that small teams have several advantages.

• They have very few communications paths, so the overhead (including a great amount of intermediate documentation) is avoided.
• In order to implement solutions to complex problems, they have to keep things simple just to be able to complete the work in a reasonable amount of time.
• Refactoring due to not understanding a function (or misunderstanding it) is minimized.
• Development builds tend to be done more often and integration problems are minimized.
• The trend is to allocate independent blocks of work to each developer, so pathological programming practices are minimized, though duplication of effort on low-level routines/classes is not. 

The disadvantages include:

• A tendency towards too little external-facing documentation.
• Internal documentation that only the original developers truly understand.
• Releases tend to be along the order of, "We're done, take it," rather than being formally packaged releases.
• Small teams are inherently limited in the size of projects they can attempt.

So from a CM perspective, what tends to get skimped on with small team projects? The following list is only a few of the more important tasks:

• Requirements Versioning - The requirements tend to be more informal and not updated in a timely fashion. The team is small enough that everyone is aware of the changes, so the additional overhead of documentation, versioning and tracking is simply not performed. It is not uncommon for small teams to do an initial cut at requirements, and then update them once the project is nearing completion to reflect the As-Built product. This does not prevent legal challenges if the customer is not satisfied that the requirements are met - especially in a contracted work situation.
• Version Control - For the most part small teams do a reasonable job of versioning the code that goes into milestone builds. The problem is that instead of following the "Check in early; check in often" approach the tendency is to check in just in time. This causes integration related issues that are considered to be just part of the process. While branching and merging will normally be kept to a minimum, provisions still need to be make to support release maintenance in parallel with on-going development.
• Defect Tracking - Small teams often track defects only once the product is in production. Any defects identified during the coding and testing stages are either handled informally or through a separate tracking mechanism. Unless there is someone on the team that likes integrated CM tools, it is unlikely that code changes (via the Version Control system) are tied to the defect records the changes implement.
• Build Engineering / Build Management - As has already been mentioned, small teams tend towards developmental builds, not controlled pre-production builds. This can cause different tool chains to be used by different developers with the result that the final "production" build may not perform as expected (or may not even build). There is also very little that ties builds to the Defect Tracking system, so it is difficult to know what was actually tested when it comes time to do a release.
• Release Management - This is often a developer function unless there are a lot of small team projects underway within an organization. In that case, the final production release may well be performed by someone who does not have the detailed level of knowledge that the small team developers have that allows them to recognize problems before the product is in the hands of the customer. If the team itself does the releases, they tend to be incomplete due to the tendency of developers to concentrate on code and not on the other components (e.g. documentation) that goes into a release. 

Does this mean that small teams invariably do things poorly? No. Does this mean that large teams are better than small teams? Definitely no. What it does mean is that small teams need to set up an easy to use CM infrastructure before they start, and then use it. There is no need for all of the process management hooks and constraints larger teams need, nor is there a need to be as sophisticated. Decent Version Control and Defect Tracking tools, especially if they are integrated in some fashion, will do most of the job. A large scale build management tool is not needed, so long as the lower level build tools (e.g. make, ant, maven, etc.) are set up to use Version Controlled source and "clean" operations are done prior to (or as a part of) release candidate builds.

The rest is just keeping in mind that the code is only part of the job. Regardless of how much one might want to ignore it; requirements, documentation, controlled release builds and release packaging are things that must also be done. Since there is rarely a large infrastructure in place to support small teams, each team must also do these activities.

One final note regarding requirements and Customer Acceptance Tests / Signoff... It makes no difference what size team one is a member of, nor does it make any difference what size organization the team belongs to; if the customer end up filing suite your only recourse is to show that the documented requirements were agree to and that the customer either signed off on them or should have signed off on them based on the results of the Acceptance Tests. The team should also be able to show due diligence in reviewing the requirements and making sure the customer signs off on any questionable ones before they are implemented. An example of a questionable requirement is an implantable defibrillator that is required to detect questionable internal states and reboot, taking no longer than 5 minutes to do so. Five minutes at the wrong time = death and most judges and arbitrators will recognize this!

Ben Weatherall is currently based in Fort Worth, Texas where he practices Practical CM on a daily basis using a combination of CVS and custom tools to support a modified Agile-SCRUM development methodology. He is a member of IEEE, ASEE (Association of Software Engineering Excellence – The SEI’s Dallas based SPIN Affiliate), NTLUG (North Texas Linux Users Group), and PLUG (Phoenix Linux Users Group).

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment