Depending on project size and component interaction, developers can often be left to design the entire individual components or subsystems. This decision provides the developer with the freedom to meet the user requirement in the most efficient and elegant design possible. This approach works wonderfully for smaller sub systems or components; however, with more complicated requirements, the more design input the better.

During a recent development project, I was fortunate to be able to work on the design and development of a portion of a system while other sections of the system were being constructed by other team members. Frequently, through the course of my development I became concerned about how the inputs, outputs, and assumptions that I was building into my subsystem would impact the interactions of my section of the system with the others being concurrently developed.

The high level design of the system that we were working with was not detailed enough to answer all of my questions so I began to communicate with my team members individually in order to increase the cohesiveness of the entire system.

Shortly after beginning these conversations it became apparent that the entire team needed to come together to discuss how individual design decisions could and would impact the functionality of the entire system. Therefore we began to meet regularly to define and re-define the overall design of the system.

Frankly these meetings were torturous at times, mostly because getting our heads around the complexity of the system we were designing took quite a bit of effort. This effort however produced an extremely solid design, which drew from all of our creative inputs and unique perspectives on the proper ways to meet the user requirements.

The following benefits were reaped from our team design meetings:

Collaborative problem solving
When a team member would reach a point of uncertainly with the development of a subsystem the team collaborated on the solution. This allowed for the solution to be conceived in an environment that drew from an in-depth understanding of all currently developed subsystems thereby avoiding any negative subsystem interactions.

Detailed impact assessment
When a subsystem redesign was necessary, due to system limitations, all members of the team were able to provide input on the impact of this change to their individual subsystems. This decreased the amount of negative impact across the system and allowed for the developers to modify their subsystems to accommodate the changes concurrently with the code change development.

Code Reuse
The design of the entire system was considered for each redesign of a subsystem. This allowed for rapid logic error detection as well as efficient use of individual subsystems. By clearly defining the purpose and being involved in the design of each subsystem, each team was able to effectively modularize their code for maximum reuse.