On Monday 31 December 2001 03:45 am, Daniel Phillips wrote:
> On December 29, 2001 11:04 pm, Larry McVoy wrote:
> > On Sat, Dec 29, 2001 at 04:03:34PM -0500, Benjamin LaHaise wrote:
> > > On Sat, Dec 29, 2001 at 11:37:49AM -0800, Larry McVoy wrote:
> > > > If you have N people trying to patch the same file, you'll require N
> > > > releases and some poor shlep is going to have to resubmit their patch
> > > > N-1 times before it gets in.
> > >
> > > Wrong. Most patches are independant, and even touch different
> > > functions.
> > Really? And the data which shows this absolute statement to be true is
> > where? I'm happy to believe data, but there is no data here.
> Ben's right. Most patches are independant because the work divides itself
> up that way, because people talk about this stuff (on IRC) and cooperate,
> and because the tree structure evolves to support the natural divisions ;)
In a fan club, saying "andrea's the MM guy, talk to him" is only natural.
It's a meritocracy, he's alpha geek on call in that area right now.
In a fortune 500 bureaucracy, people are largely supposed to be
interchangeable cogs. People's worth is measured in dollars, and somebody
worth $70k a year should be swappable with somebody else worth $70k/year.
(It's a bit more complex than that, there's certifications and experience,
but somebody with a BA and 2 years experience working on inflatable widgets
should be exchangeable with somebody else with a BA and 2 years experience
working on inflatable widgets. If not, they'll "get up to speed", it's just
a question of acquiring experience...)
So having a single point of failure in the development process... It's
unthinkable. What if that guy decides to retire? What if he gets hit by a
bus. What if the competition hires him away? What if he DEMANDS MORE MONEY?
(It's all about money in a corporation. It's all numbers. The bottom line.
So if the whole project depends on one guy, logically he'll ask for as much
salary as the project's worth. That's a lot of how management thinks.)
So if you DO have someone breaking down the project into subsections, it's
unlikely to be a developer, it would be a manager assigning areas of
responsibility. And shuffling them around from time to time so nobody gets
the idea they can't be replaced. But it's easiest just to scatter
tasks over the group and keep things mixed up all the time...
Fan clubs are all individuals. Bureaucracies try to eliminate the
individual: the automated assembly line with no humans in it is the
Totally different paradigm.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:14 EST