Software projects need to be set up in a way that encourages smooth, organic growth in the face of rising complexity. Here's how to go about it.
As everyone who has ever been part of one or simply watched one from a distance knows, software projects have a tendency to grow in complexity over time. New team members get added, the code size increases, and eventually departments other than development, such as QA and support, get involved.
It would seem natural that different project stages and teams of different sizes have different requirements when it comes to development processes and tool support. However, on most of my software projects, either there was a failure to anticipate the increased coordination required to manage the inevitable increases in complexity, or the development team was overburdened with unnecessary bookkeeping and process minutia.
The effect this can have on teams, in addition to wasted time, is critical. Teams can easily devolve into groups of "lone coders," with each member acting as an individual with no shared sense of where the project is going as a whole. At the other end of the spectrum, single members can easily get alienated when forced to deal with needless overhead and ceremony. Red tape is nobody's friend, least of all intelligent, creative, self-motivated software engineers.
The trajectory for any project goes from simple to complex and from small to large. A well-managed project will expand the complexity of its processes and tools as it proceeds and as the need arises. When only two people write the initial prototype, they probably can manage quite well without much of a formal process. However, natural extension points are important for whatever minimal process is used.
For example, most if not all projects use some form of versioning tool to manage the source code. At the beginning of a project, it may be quite desirable not to restrict access to the code base in any way, and to leverage the forward momentum that a few dedicated people working together intensely tend to develop while in the initial phases of a project. However, it is important to know how access can be restricted in the future. Once the project has matured to a certain point, changes to the code base will need to happen in a more organized way to maintain overall architectural integrity.
As more programmers join a team, it may become necessary to tighten the process further by giving senior members control over what changes make it into the system. Such a natural progression may seem logical, but most software projects tend either to specify a full change-management process at the beginning or never to set one up at all.
The general principle implied here is to keep the level of complexity as low as possible without jeopardizing the integrity of a project. This balance is, of course, well understood in Lean Project Management theory, but sadly, even with Agile Development getting more and more traction over the years, it's a best-practice that still gets applied to projects far too infrequently.
Tweet This
