Subject: Re: how to organize programmers
From: Tom Lord <>
Date: Thu, 23 Aug 2001 19:31:02 -0700 (PDT)

	Bill White writes:
	[a very funny rant ... with some good points mixed in]

	I used to believe this kind of stuff, but I've changed my mind.
	What you've suggested is in essence:
	  o Developers
	  o Maintenance
	  o R&D

No.  The details of what I proposed are importantly more specific
than that.  For example:

All three kinds of team that I proposed are focused on methodology and
on developing state as an engineering team.  I agree with you that, as
a first approximation, as a group, we don't know what we're doing
w.r.t. to software.  That's one reason why the special-teams approach
is a good idea: teams can efficiently learn and preserve what they
learn on the way to becoming capable and mature software development

The "developer" and "maintenance" teams are supposed to develop skills
that aren't specific to just one product.  That's because those skills
(rapid, reliable development and robust stewardship) don't come for
free, are incredibly valuable, are transferable between specific
programs, and can thrive in the ephemeral context of a long-term team.

In that context, "R&D" teams are focused on software basis sets -- not
on a search for miraculous easy plays that can be pushed through
otherwise broken development organizations.  I have a lot to say about
software basis sets, but this isn't the thread for that.

	The problems with this are [...]

	["management" won't get it, and will sabotage
	their host organization through political infighting
	and irrational spending]

Yes, bad management practices are something worthy of whistle-blowing,
critical self examination, and ongoing correction.  The special teams
approach is not a magic bullet that can eliminate bad management

The special teams approach *is* a correction to certain specific bad
management practices such as: life-cycle product teams, vanity R&D
organizations, and under-valuing of software custodian-ship.

By the way, I tend to think that many individual programmers will want
to move around between or play simultaneously in multiple special
teams.  That's a good way to spread knowledge and perspective, and to
help develop a mentoring-oriented engineering culture.  In that
context, your "amorphous" team approach has some resonance for me.

    This point here is very important.  An employee's competition
    in any large organization are not other companies but the
    employee's coworkers.  

The rules of the competition are determined largely by the rules of
compensation and advancement (implicit or explicit, real or presumed).
It isn't inevitable that employees will in-fight to the detriment of
the larger organization, or the customer.