

Six coders can do anything and there is nothing six coders can't do - jeandenis
http://6coders.com/whats-in-a-name-six-coders-can-do-anything-an

======
araneae
I guess 6 coders is kind of like 100 ninjas.

In other news, I don't understand why so many people would up-vote a post
which is has almost no content and is ostensibly promotional.

~~~
IgorPartola
It gets exactly 6 points

------
btilly
Quantitative data time.

In research quoted in _Software Estimation_ by Steve McConnell, for completing
a medium sized project (in that research defined as 10,000 to 100,000 lines of
code) there was a local minimum of calendar time with teams of 5-8 people. To
reach that level of calendar time again you needed a team of at least 20
people. However there is reason to believe that 50,000 lines of code delivered
by 20 people will have more duplication of effort and less quality than the
same delivered by 5. Which makes the relative productivity of the small team
even better.

The reason is simple. The natural loose and open structure of a small team
breaks down if the team is too big. Depending on the specific people, it tends
to happen somewhere in the range of 6-9 people. Past that you have to manage
lines of communication carefully, which results in process and overhead with
reduced productivity.

The lesson to draw from this is the following. If you want the project
delivered as cheaply as possible, let one programmer work as long as it takes.
If you need it delivered quickly you can increase team size to 5-8 people. If
you need stuff delivered faster than that you'd better swallow hard, accept a
several-fold increase in costs, start hiring, and do careful planning because
you'll need it.

(You can pass the small team limit in practice by having different teams on
different pieces of software. But they had better be really different. When
people have to interact closely, they are part of the same team no matter what
the org chart says.)

------
FfejL
Great! The FAA needs a new radar system. You six can tackle the software
portion. Let me know when you're done.

~~~
blahedo
You know, I'm not sure that's a counterexample. If there were six _good_ and
_careful_ coders, I think I could be convinced that they'd make a more
reliable system than a few hundred broken into several carefully-spec'ed and
rigorously documented teams, where it would be much harder to avoid having a
few bad apples, not to mention the impossibility of having even a general idea
of what someone else's code is doing.

It's not a guarantee, no. But I don't think it's a knockout counterexample,
either.

------
weeksie
Five developers is the maximum that I will put on a project. That doesn't mean
the larger hunk of software doesn't have other teams working on it; just that
they need to be separated by a well defined API (service based or otherwise).
If the project isn't big enough yet then you don't need that many developers.

So yeah, I agree.

~~~
jimfl
6 developers makes 3 pairs.

~~~
gometro33
I've used pairs off and on at work but never long-term. The part I find most
useful about coding side-by-side with someone is that there is someone to
question (or reassure) every small decision I make (for better or worse!).
Particularly in coding, there are always many ways to solve each problem and
having two sets of eyes (with even mediocre brains attached) frequently yields
a better solution.

I find that a necessary part of pair programming is to switch up the pairs
fairly often. Pairs have a tendency to become "comfortable" with each other's
habits and can fall into a rut -- pairs should be shaken up to keep each
everyone on their toes.

Also, you can learn a lot (about programming, people, life, etc.) when pair
programming.

