One of the best and worst uses of time on a multi-person project are the inevitable debates around architecture and design. Unfortunately, these debates can sidetrack the participants, and become a mano-a-mano test of debating acumen, neither of which are especially conducive to producing software on time. This article discusses the value of a shared philosophy among team members.
Linus Torvalds (of Linux fame) has a saying that “Many eyes make all bugs shallow”. Similarly, project teams should have a process whereby the collective wisdom of the team members should cause Bad Ideas to die a quick and painful death.

The challenge with this is that it is often difficult to separate the message from the messenger. While the senior folks on the team are usually correct more often than their less-experienced counterparts, this is not always the case.

In order to keep lively debates from devolving into a “spitting contest”, euphimistically speaking, it’s important to allow Bad Ideas to die with minimal collateral damage to their creator.

The way that we do this is simple: We set out early on the project to gain consensus on a number of core principles or beliefs that the team has about the project and the resultant software. These are often broken out in terms of:

• People Issues (User experience, stakeholder expectations, team member specialization, etc.)
• Process Issues (Requirements management, testing strategies, build/release management, etc.)
• Technology Issues (platform considerations, “No Premature Optimization”, role of database, etc.)

Once we have consensus on the high-level beliefs, then many subsequent debates can be judged not solely on their individual technical merit, but also in terms of how well-aligned they are to the higher principles that the team is marching toward.