Code Leader: Using People, Tools, and Processes to Build Successful Software

4.1. Discuss Design Decisions

Any significant design decisions should be discussed and approved by the team. There is a fine line to be walked here between getting people's buy-in and the dreaded "design by consensus" syndrome, but I think it is an important rule to establish. Design by consensus cannot work and is never what you want your team to spend their time on. Everyone has opinions about how every piece of code should be designed, but at some point, there needs to be one hand on the tiller. The role of designer/architect is an important one, but "architect" doesn't need to be synonymous with "autocrat."

Personally, I favor an approach in which one or a small team of architects sketch out an initial design, preferably as part of a baseline architecture. That means building out as wide a solution as possible that touches all the riskiest parts of the design without going too deep. You want to prove that the solution is viable without spending much time building features. Once that initial work has been done, additional design work falls to the rest of the team. The architect should be responsible for the top-level design, but asking the architect to be responsible for designing every corner of the system is neither practical nor beneficial. That means that there will be some design work assigned to each member of the team as they build "down" or add features to the skeleton established by the baseline architecture.

That said, it is still the responsibility of the architect ...