Johan Nilsson wrote:
So you mean that a single capable person beats a group of capable people?
No, not in general. I just think that intuition, IMO the primary ingredient in the initial design phase, isn't something that can easily be spread over multiple brains. You can surely collect requirements, opinions, etc. from a group, but I've never seen a coherent design spring from more than one mind at the same time.
I must agree on the coherency stuff. Perhaps our definition of what should go into a *draft* design is what makes our opinions differ.
That could well be, see below.
I've worked quite some time in so-called "architecture teams", where multiple people sitting in one room try to design something.
(as a side-note: I'm not too fond of the term "architecture teams". Everyone should be allowed to be an architect, if they like to and can add some value to the process.)
Perhaps I need to clarify that those meetings took place only in the early stages of the project and all people that were involved in the project at that time were always invited (at those stages usually only a fraction of the later manpower was available). Later the architecture team existed only to take decisions on usually small stuff that cropped up or to review redesigns (because of requirements shift or because a particular design was found to scale badly).
I agree, that's why I think that an individual should work out a draft design all by himself and then present it to the group. After the group has responded she can go back and resolve the raised issues and refine the design. Depending on the complexity of the library, it usually takes several such rounds before the design is reasonably complete.
Again - what goes into a "design"? Must a draft design really include a fully compilable, usable library? Couldn't it just definition of concepts, overall design and suggestions for detailed implementation (perhaps proof-of-concept code where deemed necessary)?
That really depends on a number of factors. If the design involves stuff (details of the problem domain, programming techniques, etc.) that is not very well understood by most members of the reviewing group and/or the design will likely have an impact on a lot of code of the project then I usually insist on a proof-of-concept implementation complete with an implementation of a small real-world use-case. For a library where the focus, the implementation and the impact is much smaller there can well be a decision before a single line of code is written. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.