Granularity

[Myk Melez]

MattyT wrote:

>I fail to see how this justifies not receiving peer review.  Peer review
>is at the core of the good volunteer projects and is why they produce
>good software.  The logical extension of your argument is to never talk
>about designs at all, since someone might complain and bog the bug down.
>

This has nothing to do with peer review, which I absolutely agree with. 
 It's about whether or not everyone should get involved in each review.

>It is not "design by committee" if someone holds a big stick and is
>willing to use it quickly.  You also have not offered any proof that we
>are worse off in the long run through having the discussion on mail,
>even if it did get bogged down for a while.
>

If you agree with my assertion that all the alternatives were at least 
good enough (and, fwiw, the participants in the debate seemed to feel 
this way last time I checked with them) and that the fix would be better 
than not having it, then it's clear that we are worse off now than we 
would have been if one of those fixes had gone in.

>When things get "shunted
>through", you often are sacrificing your long term quality for short
>term gains.
>

But I'm not talking about "shunting" anything through at all.  I'm 
talking about patches that get reviewed (sometimes repeatedly) by one or 
more experienced hackers before going in and that provide significant 
benefit to the code, even if they sometimes have flaws (which we also 
didn't catch back when we were doing two reviews).

>If Bugzilla had been designed from the start to be templatised,
>internationalised, fully field value customisable, run in taint mode,
>back end separated, blah blah blah, we would have been where we are
>today a lot earlier.
>
More likely we wouldn't have been anywhere at all (cf: Bugzilla 3.0). 
 Only huge engineering projects (f.e. rockets to the moon) can be built 
this way, and only by expending an incredible amount of resources 
beforehand, disproportionately large relative to the size of the 
project.  Bugzilla is certainly getting larger, but it isn't nearly 
there yet.

>  Obviously there were time constraints placed on
>Terry by mozilla.org that led to these decisions.  But most of us now
>are individual developers who don't have to continue to make these sorts
>of decisions.  A little time invested now pays off big in the long run.
>

I contend that reviewers and regular "viewers" regularly invest that 
time now, often more than is necessary, to ensure that the code that 
goes in takes our future plans and current standards into account. 
 Overexuberance in this regard is, in fact, one of the reasons (although 
not the major one) why our reviews take so dang long.

And you also have to consider the law of diminishing returns.  There's 
only so much discussion you can have before it stops being useful and 
you're better off implementing your current best guess and fixing any 
problems down the road.

>Also note that you're much more likely to notice deadlocked design
>discussions on this list because historically they're generally already
>deadlocked by the time they get onto the list, as they have started on
>IRC or on bmo, and escalated.  They're also longer, more memorable
>threads because of the argument.  Hence I think the argument factor is
>quite an exaggeration.
>

I think an increasingly common case is that someone posts a message and 
then everyone jumps into the discussion with their opinion.  Over time 
the opinions start to take on weight and harden, and then it becomes too 
important for everyone's opinion to be taken into account in the final 
design.  The first half of this dynamic--the jumping in with 
opinions--has already happened today with Christian's CVS integration. 
 Hopefully the second won't.

-myk