Also Known As:
Schedule pressure overpowers a new team.
A newly formed team is given a new project characterized by the following:
tight schedule, changing requirements, uncertainty of design, uneven
distribution of skills among developers, and new technologies.
- Schedule is paramount
- Only one or a few, at best, really has the domain knowledge and/or technical skill to immediately attack the project
- Team dynamics not yet formed
- Personalities clash
- CultOfPersonality may develop
Let the most skilled and knowledgeable individual drive the design and
implement the critical pieces.
Concentrating the critical responsibilities upon an individual eliminates
much of the communication complexity and meeting time spent organizing the
team. The Guru decides what must be done, chooses the choice parts for
herself/himself, and dictates what else must be accomplished by the
remainder of the team. Design knowledge does not necessarily need to
be disseminated among developers, particularly if all interfaces are designed
by the Guru. Negotiation is kept to a minimum.
Caution: Guru must have people skills, and guru must be very good at delegation.
(Otherwise Guru becomes bottleneck / LongPoleInTheTent.)
When expertise among team members is so extremely
varied that training and team building cannot possibly bridge the gaps,
the Guru can distribute work according to abilities and inclinations. The
Guru can also present the unified face to management (see LetsPlayTeam
What about GuruReallyDoesAll?
Hey, wait a minute! There's an important pattern that rightfully owns the name GuruDoesAll
, and it's not what's described above. The pattern is: "My team can't do the job, but I've got a guru on hand or can buy one. Therefore: let the guru do everything
--even the artwork on the marketing brochures." This completely blows away ExtremeProgramming
or any other development method for projects where you have an appropriate guru and the project is small enough for one guru to do (rough what ten-non-gurus can do without a special discipline like XP). You get a beautiful, brilliant, elegant, innovative, virtually bug-free, organic, truly well-designed system. It will amaze all your friends as well as the marketplace.
Productivity between programmers varies by orders of magnitude.
Most management methods concentrate on getting the most out of mediocre programmers. GuruDoesAll
is just a different technique: exploiting one truly top-notch programmer to the limit. If the guru costs three times as much as ten mediocre programmers, you're still getting a gigantic bargain.
- Almost never works with more than one guru. Rare is the guru who can synergize well with another guru. Occasionally you run into a genuine two-guru team, and that's pretty well unbeatable by anything except real large-scale teamwork (which is about as difficult to achieve as finding a guru).
- Many programmers think they're gurus and aren't. "Many are called but few are chosen."
- Many gurus are super-productive when they're juiced for the job, and worthless when they're not. You not only have to pick the right guru for your job, you have to wake him up at a time when the job offers him the kind of challenge he's interested in at that moment. A technique used in some large organizations is to keep the guru around for long non-productive periods during which he mostly sleeps a lot, drinks MountainDew, and reads WardsWiki. Then he's well-rested and available when you need him on a critical project.
- You must not let the suits see the guru. Certainly don't let them talk to the guru! Most gurus have no people skills. If you play your cards right, he won't need them. (Guru does all, remember?)
On the other hand, the Guru becomes a bottle neck. This is a high risk strategy. What happens if your Guru is hit by a truck?
The important contribution of what's called here "the Guru", otherwise known as GrandMasterProgrammer, is to lay a great foundation. If your TruckNumber is one, then you better get that One to work quickly and not squander the time before the truck strikes. If your other programmers are so poor they can't maintain Guru's completed design, then you have bigger problems than your TruckNumber. (But don't feel bad, this is the norm.)
Chances are you have an underling that can learn much from Guru's code and perhaps make your TruckNumber two. When searching for these, look at the bottom. Guru potential is primarily a matter of innate aptitude, not mere experience, so your experienced programmers who are not yet Gurus possibly never will be. And of course, only your Guru is qualified to make this assessment. So, again, get to work before the truck strikes.
You probably want to remove any distractions from the Guru. Maybe give him or her the equivalent of a secretary. Perhaps meetings with management are not the best use of the Guru's time. This is discussed at some length in Brooks's MythicalManMonth
I have a request. When you write ResultingContext?
, could you please give the new problems that will have to be solved? I don't tend to believe resulting contexts which read to the effect of "... problem solved..." If that is all there is to say, then the section can be omitted. I have found that a solution opens up new topics to address. It is those topics that are interesting to document and which give power to the section. I am looking forward to what gets filled in that section.
A question I have on occasion: any advice on SurvivingGuruStatus
can ameliorate problems with TheLoaner
For me GuruDoesAll
is an overrated pattern.
Cognitive blocking of (development) of other
members often makes it anti-pattern enough.
Putting it another way: Use with extreme caution:
The Rest of the Team must be very good in
working in small scope....No Guru without
adepts en sectism..Potential harmful at
various levels! Provide also deprogramming
--Some OO psychologist, RE
Supposing that the majority of people are conditioned to look for some individual human guru of some kind, let's try to get the most out of this psychological structure. What about exploring the replacement concept of this rigid (anti)pattern and generalize it to the concept the Net Is The Guru
. See GuruNet
for a useful step in this direction. -- FridemarPache
Another way to ameliorate the risks of this setup would be to use SurgicalTeam
, as described in the MythicalManMonth
, as mentioned above. Since the master programmer in that setup has a main assistant / shadow (hmmm... must re-read that - this might be an early reference to PairProgramming
) that knows everyone he does, at least your TruckNumber
goes up to two.
Could we see GuruDoesAll
as the initial situation, with SurgicalTeam
as a pattern to improve it? -- BurkhardKloss
In my personal experience, one guru alone can very often code faster and with less errors than a guru and five mediocre programmers. Various projects I have been on could have been done vastly better and months faster without those five programmers.
Another danger is that management, after a few versions of the project, tends to make the guru the technical lead or project manager, without taking away the guru coder responsibilities. That's the quickest way I've ever seen to create a bottleneck.
There is a great relation with "Conway's Law" and Coplien Organizational patterns. Software architecture and organization structure (communication, message flow) are isomorphic.
Would this fit into an IdealDevelopmentTeam?
See also Primal Development [http://blogs.msdn.com/mattwar/archive/2007/10/17/primal-development-methodology.aspx
See also: HubDeveloper
(when it works not)
(when it works)