I think the fact is that the grass is always greener somewhere else, and
all approaches have their problems.
And it's always easier to point out problems with existing setups than
it is to come up with constructive changes. People end up wanting to
re-design everything, because that way they can make sure the problems
are gone - without really even knowing what new problems will appear
after a re-designed process.
The same thing happens in coding too, of course - you just _know_ you
can solve some problem by changing how something is done, and when you
actually code it up, you notice that "yes, I solved the problem", but
you also notice that "but now I have this other thing..".
This is why trial-and-error is such a powerful way of doing things: try
many things, and yes, they all have their problems, but on the whole you
probably end up selecting the approaches where the problems are the
_least_ irritating.
The BIG problem with things like project management is that you simply
_cannot_ do lots of different trial-and-error things. Sure, you can
try, and you'll get very Dilbertesque results: "The answer to all
problems: re-organize".
Anyway, I'm actually personally willing to make small trials, and right
now I'm trying to see if it makes any difference if I try to use BK for
a month or two. I seriously doubt it will really "fix" everything, but
neither do I think big re-organizations and patch-lists will. But I'd be
stupid if I wasn't willing to try something.
(So far, trying out BK has only meant that I have spent _none_ of my
time merging patches and reading email, and most of my time writing
helper scripts and emails to Larry to make it possible to use BK in sane
ways that suit me. And I'll doubt you'll see any real productivity
increase from me for a while ;)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/