Guru Does All

Also Known As: ProjectSavior?

Problem: Schedule pressure overpowers a new team.

Context: 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.

Forces:

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

Solution: Let the most skilled and knowledgeable individual drive the design and implement the critical pieces.

Resulting Context: 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.)

Rationale: 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).

Author: DonOlson 95/09/14

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.

Some provisos:

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?)

-- BenKovitz

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? [See TruckNumber]

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. -- DaveHarris

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. --AlistairCockburn

A question I have on occasion: any advice on SurvivingGuruStatus? --RobCrawford

GuruDoesAll can ameliorate problems with TheLoaner. --FabianLeGayBrereton.

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 sessions:-) --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??