B.S. If you devise a team sport, then the rules make it pretty much impossible to have a lone wolf. You need the team.

However, programming is NOT a team sport. Never was, and except for those grasping at straws, never will be.

"Team programming" is just an excuse by cheap management to allow them to hire a bunch of second rate programmers in the hope that they will produce like the very best. But, like the proverbial million monkeys, it's only an anecdotal pipe dream!

-S

The logic may look good, but personal observation by myself and a gentleman name Robert McClure casts some serious doubt on its validity. I have observed several SW projects over the years, and Dr. McClure observed many more. The impression/conclusion we both came up with for moderately complex/sized projects was that no matter (apparently) how competent the team members were, nor how much they uncerstood about the concept of teamwork, if there more than a very few (3 at most seemed to be the breaking point) the time went up almost exponentially and the "quality" of the end product went down in a similar fashion.

A disheartening result ...

On the other hand, I can point out 3 projects done by a single individual that got done in a relatively short time and were excellent end results:
1. Dr. McClure built TMG, one of the first syntax-driven compiler-compilers, by himself at UT in the early 1960s, refined it at TI about the same time, presented a paper at (I think) at the 1963 or 1964 FJCC.

2. Another very competent person built a complete monitor that would run on any S/360 - boot from tape, cards or a programmer's very own 2314 disk pack; made for development application programmers to use - *not* for typical IT use, but a lot of money-making work was done using the system. He was in grad school at the time, full-time student and also built a handful of other products concurrently in his spare time.

3. Roger Hall found out I knew a bit about the S/360 and S/370, picked my brain about data management/services. Took it upon himself to re-implement William Waite's Stage2 macro processor in assembly instead of the Fortran version one would normally if using the book Professor Waite wrote. Mr. Hall did most of the work on one of the TI minis from that time (1973) and transferred the ASM source to a mainframe; did it on his own free time at night and on weekends. The final processor was a couple orders of magnitude faster than the "normal" processor and, it turns out, all the implementations of Stage2 on various machines are compatible except some have more features (nice but not necessary extras) than others.

So, I don't know that this proves that there are exceptions to the theory that teams are more productive.

One reason it may be difficult to find a reference is that it is not true in many cases.

I will give you an example. A room full of IQ 140 Physics PHDs does not equal one Einstein.

The general case in which it is not true (which leads to the cases in which it is mostly true) would be SCALE based. As long as one person can produce the result in a reasonable (say under x months) time, a gifted person will almost always beat the team. They do not have the coordination and administrative overhead.

Sometimes a TEAM paradigm blocks perception. For example: Special Relativity (S. R.) is generally cited as the reason that FTL is impossible. First thing to remember: Special Relativity is a scientific theory. The belief in it (or the probability that it is true) depends on how well it predicts behaviour.

The second thing to remember is: Scientific theories are about MEASUREMENT, not reality or the way the Universe is. They do not predict reality, but what our Scientific measurements of reality will be.

Special Relativity makes the speed of light the yard stick (i.e. invariant) and derives everything from that. Once you have agreed to that, the material axiomatics of Math apply and all derivations are ‘true’. Other equally valid assumptions are possible.

To illustrate, once you have accepted S. R., then exceptions to it are interpreted through it’s filters.

Consider the example of the cosmic ray (oft cited as a “proof” of time dilation), it produces a short lived particle which could not make it to the earth in its lifespan. Therefore, time has been dilated.

Suppose that it traveled faster than light… We would (having accepted S. R.) have to explain it via time dilation. Similarly, once we accept a theory (or filter), any examples of faster than light (or any contradiction to any theory) must be explained in terms of the theory.

So we may have an example of FTL right under our nose, but we can’t see (measure) it since it is longer than our yardstick.

Just a thought or two …

I look at the various teams in my department, and it seems to me the ones that succeed best are the ones who a) have the best direction b) adapt best to changes in that direction and c) understand their role on the team. All of which are more about the leadership, than the team members themselves.

Maybe this may fall into the definition of good employees vs. great employees. But to go back to your Favre reference, he's a true leader. And great leaders make good employees great.

Back in the mid-1960s, management consultants used a group "game" called the "Lost on the Moon Game" from NASA. You can look this up on the web and find the worksheets.

The premise was that your shuttle had crash-manded on the moon 200 miles from the "mother ship" and you had a list of items that survived. You were to rank them in order of importance for your survival. You got points for each position your list varied from NASA's official list. (Low score wins.)

Then groups of co-workers prepared, by consensus, a group list.

Supposedly, the group list always out-scored the best individual score. The pooled knowledge, intuition and creativity made the group better than the individual.

Perhaps NASA or the individuals who have posted the worksheets have some data on the game? (Though given the more recent NASA controversies, this may not be a good referral.)

Wayne

Why is this even an argument? If a project is small enough to be completed by one person in a reasonable amount of time, and is a "one-shot" that will be replaced rather than maintained over a long period of time by different people, then having a single really great programmer do the project will be faster, and probably result in a better product, than trying to give it to a team.

For projects that are larger, or have to be maintained for a longer period than the original author will be available, a team approach is better. I've been a victim of what I call the "guru" approach before. A brilliant programmer writes a great program. He moves on, to retirement, to a better job, to a higher-valued project in the organization, and his code is left to be maintained by someone merely competent. "Guru," because the code is obvious to him, doesn't bother with a formal design or documentation. "Competent" then has a huge job figuring out what he's been left with and how to maintain it. A team approach forces at least somewhat more formal documentation. As the team parcels out the work, everyone has to know what to expect from each other's code. The organization also then has more than one person who understands what the code implementing the project does, so that when one member leaves others can train a new member.

Two more points. Even if we agreed that the single great programmer approach was best in all cases, where are we going to find all of these great programmers? I don't know what talent pool others are drawing from, but I can hire a whole lot of journeyman programmers before I strike gold with one real wizard. Further, journeyman programmers tend to be strong in different areas; putting them in a team allows division of labor. Successful organizations of any size have to get good at the team approach because most of their hires will be average programmers.

Finally, even in a team approach, there's still room for brilliance, and part of leadership is identifying those people and using them properly. My organization takes its best people and makes them sort of in-house consultants. When there is a really difficult problem to solve or a nasty performance bottleneck in some code, the team with that problem can call on these folks to solve a specific problem, rather than wasting a large proportion of our gurus' time writing mundane, everyday code. It keeps our best people challenged and happy and our journeyman folks get to learn from them.

As a Manager, my personal experience convinces me that this is a common management fantasy believed by the naive. Every time, I'm been on a team, at best the team has to carry non-productive members. More often, the dead wood actually get in the way, distract the ones who accomplish the work or foul up work done by others.

All that putting people on a team creates is a situation where a supervisor (called Team Leader, as a cruel joke) is given the responsibility for a project without any authority over the resources assigned to the project. No accountability. This basically is what inept managers hype, to further insulate themselves from the work. It is a great way for inept managers to appear to be showing initiative.
"Let's form a team to solve this problem...".

What is required to do a project which cannot be done by only one person? Assign resources and give authority over them, to a responsible supervisor who then assigns, directs and coordinates the work performed by those resources.

Another very similar typical management fantasy is to group all of the people that perform a type of work (like programming) into the same physical location. The fantasy is that there would be all sorts of high level interaction etc. going on. Usually, this actually just means crowding too many people into one area and crippling them with noise and distraction. It IS a good way to create a zoo. This is appropriate only in a small way, where a senior resource is training junior resources.

I have found that if, in the same physical area, you put small groups of people with similar jobs together with other different small groups, thusly in that area encompassing a whole business model, lo and behold, you get understanding, collaboration and new, original, profitable ideas from their interaction...
I call it JB's small business advantage...as it imitates the atmosphere of a high growth, highly capitalized, small business.

My thanks to you for your column and to others that contribute comments.

Amazing that after all this time, it's so hard to quantify these things. Makes it kinda hard to call it computer "science," doesn't it?

If no two people come up with the exact same solutions or conclusions, we're more into the area of "art", aren't we?

Perhaps if operating systems stayed stable more than a few years (requiring changes in everything built upon them), we would have time to make some progress....

A few years ago I read about something called "extreme programming." The idea was that people, of comparable ability and experience, would program in pairs.

The claim was that the error rate was greatly reduced and productivity was much higher, both by traditional metrics and by common sense criteria (software delivered when promised, works as promised, no feature creep or bloat, very maintainable, well documented, etc.).

The approach was very much against the idea of the "guru" or "lone ranger" code slinger generating software cantatas, concertos, and symphonies in frenzied bursts of creative mania (like a NAVY SEAL programmer "Hell Week").

It had a fair amount of open source/left wing philosophy (read: baggage) associated with it. In spite of that negative, there seemed to be some innovative ideas. It would certainly be useful for training/school scenarios.

The main problem in a corporate environment would be how to fairly assess each individual contributor's productivity and value to the team. The potential for strong/weak teams was high and would require close monitoring of all participants by project leads. Definitely different from dividing modules up among people and seeing who produces and who doesn't.

Anyone hear anything further about this? I've been away from things due to illness and unemployment. Just curious.

Also, regarding the special relativity comparison, I don't think that's instructive here because science and engineering are two very different intellectual processes.

While Einstein is rightly honored for special relativity (except by Stockholm: he got his Nobel for the photoelectric effect), he built on the work of Lorentz, Fitzgerald, and others who had been examining the same problems for some years. General relativity, however, was a singular paradigm shift on the level of Copernicus, Newton, and Darwin.

Those for and against teams have valid arguments. A great performer given a well matched task will beat a team given the same task - because the communication is totally efficient and the contribution is uniformly excellent. Nonetheless, great performers are hard to find (particularly if you have to draw more than a sip from the great normal curve of talent), some tasks require a range of expertize that's not available in a single person, and there has to be a way to nurture even great performers. A team may not always be the best solution, but to say that they seldom or never are rings of limited experience and/or vision, and a lack of [flexibility in] leadership. And no I don't have numbers either, but a substantial portfolio of personal data.

In my experience, a *cohesive* team, which automatically includes the leadership of the team, is more regularly successful than a collection of people who may be more individually skilled, but are expending lots of energy in non-cohesive ways.

This is different from the question of whether or not a team is always required to do work that could otherwise be handled by a single individual. Yes, there is overhead when more than one or two persons are involved in any endeavor, but a well-governed group provides significant scalability that goes beyond their individual ability to accomplish tasks.

I would submit that a great collection of individuals without sufficient leadership (internal to the group or external to the group) is not a team. Likewise, a collection of individuals that has great leadership, a clear mission, and focus, is a solid team, despite where those members might otherwise rank in skill as individuals.

It is the total picture that is necessary. Sometimes overwhelming leadership ability can make up for missing skills in other areas, or a single dominant skilled *player* can compensate for other missing components, but cohesiveness and continuity of direction is always critical.

It is my belief that an individual can build a great system, but it takes a team to polish it. This is not to knock great developers, but even great developers have their blind spots.

In other words a great developer can get a system to 80% or even 90% completion quickly in a short time, but to get it into the upper 90%'s can require more time than the team would have taken from start to finish. It is just that the individual developer's work will be viewed less critically than a teams work.

Funny story about the "survival game". When my NASA-contractor company got on the Continuous Improvement bandwagon, the first day of training we ran through the "lost in the desert" scenario pretty much as described.

The end result is that my choices were much better than the team result, because the team was convinced by a few who *thought* they knew salt was the most important thing to have overrode what I said.

Of course, salt will help you die even more quickly..and so the team result was horrible. Multiple lessons to be learned there (among which perhaps I could've tried to be more adamant :) ).

In any event...the trick is to know when to pick the wisom of the team or an individual.