[boost] Re: Re: FORMAL review process not working well?

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2004-11-02 03:48:14

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.