> [16] Design as a team; implement as individuals.
This is pithy. I'm curious - does anyone here follow this philosophy? How do you actually design as a team? A meeting for every single design decision?
I'm used to the team finding general alignment on the problem in meetings, but then a single person coming up with the design, writing a doc, and circulating it for comments.
We wanted to ensure everyone on the team has explored the full design space, and everyone agreed that the chosen solution is the best we can think of, given the current information and constraints.
Once we have done that, everyone is aligned and it doesn't matter who to implement it; it will be implemented in the same way.
I think your example could be seen as designing as a team, its just one person who does the writing, but everyone who needed to be involved was involved.
On a smaller scale I've worked in teams where when someone picked up a story, for certain cases we would first do a rough outline of the implementation and then take that to one or two devs from the team, just to talk about how to tackle the problem. Not a meeting, just five minutes of "here's what I think would work". Its hard but good alignment before writing code really helps with finding the errors in a design.
Within a high level design there's often a lot of room for variations in the implementation such as code structure; though this freedom decreases significantly if you have a wide enough audience to need to consider Hyrum's Law.
Concretely, let's say I'm designing a term-rewriting system. The program will be inspecting an abstract syntax tree (AST) for certain patterns, and if it detects those patterns, rewriting them. (e.g. if we see the AST for "1 + 1" rewrite to "2"). I might write up a document on the architecture for the system, and a list of rewriting rules I need. How those rules are written can be left up to individuals on my team as long as it fits into the architecture, has the required functionality, and is of reasonable quality.
I understood this advice as "avoid doing parallelized design work", where "team" means a single coordinated actor rather than a bunch of individual streams. I don't think the emphasis here is collective design.
This is pithy. I'm curious - does anyone here follow this philosophy? How do you actually design as a team? A meeting for every single design decision?
I'm used to the team finding general alignment on the problem in meetings, but then a single person coming up with the design, writing a doc, and circulating it for comments.