Messages in this thread | | | Date | Wed, 30 Apr 2008 18:40:39 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Slow DOWN, please!!! |
| |
On Wed, 30 Apr 2008, Linus Torvalds wrote: > > You (and Andrew) have tried to argue that slowing things down results in > better quality,
Sorry, not Andrew. DavidN.
Andrew argued the other way (quality->slower), which I also happen to not necessarily believe in, but that's a separate argument.
Nobody should ever argue against raising quality.
The question could be about "at what cost"? (although I think that's not necessarily a good argument, since I personally suspect that good quality code comes from _lowering_ costs, not raising them).
But what's really relevant is "how?"
Now, we do know that open-source code tends to be higher quality (along a number of metrics) than closed source code, and my argument is that it's not because of bike-shedding (aka code review), but simply because the code is out there and available and visible.
And as a result of that, my personal belief is that the best way to raise quality of code is to distribute it. Yes, as patches for discussion, but even more so as a part of a cohesive whole - as _merged_ patches!
The thing is, the quality of individual patches isn't what matters! What matters is the quality of the end result. And people are going to be a lot more involved in looking at, testing, and working with code that is merged, rather than code that isn't.
So _my_ answer to the "how do we raise quality" is actually the exact reverse of what you guys seem to be arguing.
IOW, I argue that the high speed of merging very much is a big part of what gives us quality in the end. It may result in bugs along the way, but it also results in fixes, and lots of people looking at the result (and looking at it in *context*, not just as a patch flying around).
And yes, maybe that sounds counter-intuitive. But hey, people thought open source was counter-intuitive. I spent years explaining why it should work at all!
Linus
| |