Rick Stratton 22 Aug 05

Does that mean three people total? Or three developers?

Mark 22 Aug 05

I think that needs to be qualified to the type project. For instance, an e-learning type application (even for v1) is going to typically take 4 people -

- SME (subject matter expert)
- ID (instructional designer)
- Graphic / UI designer
- Coder

Sure, you might be able to combine some skills, but this is typically the minimum setup.

Blinksale 22 Aug 05

It’s a pretty accurate statement. Blinksale was built with “three” people. One designer/manager, one developer, and two half-timers working on various design and documentation details.

Eamon 22 Aug 05

Three sounds about right.

JF 22 Aug 05

Does that mean three people total? Or three developers?

3 people total.

Our original Basecamp team was 3: Myself and Ryan on UI, and David on programming. Backpack was the same, except David and Jamis split their time.

My recommendation would be to go with 2 UI and 1 programmer instead of 2 programmers and 1 UI, but it can work either way as long as you have the right people.

Troy Hakala 22 Aug 05

IBM did a famous development test years ago (the 1970s?) where they had two teams build the OS for their new mainframe. One team had 5 people and the other had 100. The team of 100 never finished and were late on every milestone, but the team of 5 finished it earlier and had fewer bugs. I’m recalling this from memory, so these numbers may not be totally accurate, but that’s the gist of it.

Teams that are too large get mired in bureaucracy, process and egos. This is probably true for everything, not just software development.

JF 22 Aug 05

Does anyone know the exact name or results of that study? Or a link to the findings somewhere? Thanks.

Ethan 22 Aug 05

I agree here… Sat in a room one day with 70 people almost crapping my pants buring 10k a day. Threw everyone out and did the same with 5 people in 90 days - for a version 2 of a product.

E

Brad 22 Aug 05

It’s not intuitive though (from a management perspective), so for those of us on the convincing end, it’s not as easy as saying, ‘hey, it will be cheaper, better and on-time’.

JF 22 Aug 05

It�s not intuitive though (from a management perspective), so for those of us on the convincing end, it�s not as easy as saying, �hey, it will be cheaper, better and on-time�.

One way to do it is to flip it: Are we CURRENTLY delivering cheaper, better, and on-time?” No? Maybe it’s time for a change.

Joshua Porter 22 Aug 05

Love the constraints riff (or the renewed focus on it), but how about some more real world examples outside of the basecamp/blinksale paradigm?

How many folks were on Flickr, Skype, Gmail, and other highly successful projects that may be worth emulating?

How many projects starting with 3 folks fail?

Also, is it safe to say that when you say one programmer, you mean “one programmer who is talented enough to create a widely successful web app framework”? I program…and use my own little app framework…but I’m certain I couldn’t whip up ruby on rails in the fashion that David did.

harry 22 Aug 05

Not sure if the exact “study” Troy referenced is in their, but The Mythical Man Month (1975) by Fred Brooks talks a lot about the benefits of prototyping and a small team (what Brooks calls a “surgical team”).

Darrel 22 Aug 05

It�s a pretty accurate statement. Blinksale was built with �three� people.

Though blinksale is necessarily a benchmark product in terms of development time.

I think the point of the post is ‘less is more’ when it comes to staffing a development team and erring on the side of less may actually be a good thing. To say 3 people, period, just isn’t terribly accurate in reality, but it does get the point across in a nice soundbite.

Oh, and of course, if we want to measure the true success of a product = sales, then we, of course, need to add the entire marketing department to the payroll. ;o)

JohnO 22 Aug 05

Fred Brooks Mythical Man Month is key on this. He produced/managed enterprise (Fortune 500) company internal systems. He said that anything that takes more than 10 programmers is a waste of talent/time/features. None of us are making enterprise systems here (I’d think), so moving that number to 3 for us is applicable… But, let’s all keep in mind this advice has been out there for 30 years now.

Mark Kawano 22 Aug 05

FWIW, Photoshop version 1 was created with only 2 people: the Knoll brothers.

While I don’t want to get caught up in actual numbers, I totally agree that v1 products need to be built with small teams. The inability to value and create small teams is just one of the reasons why software giants acquire their products rather than build them in-house.

And yes JohnO, this advice is not new.

Jason, the idea of 2 UI designers and 1 programmer is crazy to me. You need the right people, not the right job titles.

Mark Kawano 22 Aug 05

“You need the right people, not the right job titles.”

Which is what you said, originally, but I wanted to reiterate this point because IMO this is the most important factor more than the exact number of people or their titles.

Cody Lindley 22 Aug 05

This manner of thinking seems to assume that 3 highly talented, experience, and capable individuals are easy to find & keep. Why do we throw 100 developers at a project? It seems to me because finding three good developers is actually very difficult. Not to mention that the skill sets also need to compliment each other. Its a great ideal for small teams, but large companys need to create small teams before they can understand the benefits of having 3 rock stars working on a single project.

Thomas Baekdal 22 Aug 05

I do agree about keeping the team members on new projects to a minimum, but what about version 2? or version 10?

This is where it gets problematic. Version 1 is usually not that hard - you got the energy, the momentum, the spirit and the freshness of things.

Version 2+ also includes a lot of added elements in terms of what to improve, for whom, in what way mixed with tons of request from clients.

I have a golden rule when it comes to software:

Version 1 is great - a simple thing of magic, although not fully useful
Version 2 is a hack - trying to please everyone
Version 3 is useful - with renewed focus and a more detailed product.

As is it with the people involved

Version 1 includes a small group of people
Version 2, being more about compromises, it includes a very large group of people (managers, important clients, interest groups - you name it)
Version 3 has effective amount of people (which varies greatly depending on the kind of project)

David 22 Aug 05

LOL.

No really.

LOL.

Jack 22 Aug 05

@Thomas Baekdal:

I apply a similar set of rules to movie franchises.

Frank Spychalski 23 Aug 05

amen!

Megan Holbrook 23 Aug 05

I’d add one more team component that was left out: bug tester. It’s often hard for a team that has designed and programmed a piece of software or website to see its flaws (sometimes glaring). Having a new pair of eyes, or several pairs, to do at least informal bug testing is quite useful…

Abdul Ovaice 23 Aug 05

Jason,

Why 2 UI designers?

- abdul

Craig Schock 23 Aug 05

While I agree that small teams are better, I do not agree that 3 is the magic number. Having 3 people on a team can lead to one of the worst team dynamics: 2 vs 1. Having worked on a lot of teams myself, I have generally found teams of 4 to be far superior. I think Megan’s point about testing is also very relevant to this. With three people, there isn’t often enough time available for testing.

Michael Daines 24 Aug 05

Small teams? How about small houses?

Jess 24 Aug 05

That doesn’t make sense Craig. When it comes to disagreements on something it’s easier to settle it when you are 3.
What are your experiences when you come to a disagreement where it’s 2 vs. 2?
My experience is that people get stuck.

James Webster 24 Aug 05

What about pair programming? Surely the minimum should be four then!

Craig Schock 24 Aug 05

Jess - The dynamic that you’ve mentioned (2v1) is the problem. What can often happen is that 2 people “gang up” on the third. The result is that the third person’s ideas are often not considered. This can generate a lot of resentment. It is far better to have 4. Resolving 2v2 usually results in far better solutions.

Jess 25 Aug 05

Thanx Craig. I’ve never experienced a situation like that in the company I’m currently working at (We are 3 people). But I can perfectly image the “ganging up”. In fact, come to think about, I have experienced that before at the university when doing group-work. So I guess it can happen just as well in companies.

Wesley Walser 25 Aug 05

That makes starting a web startup sound really easy, atleast for hiring. If I interview 200 people I am bound to find atleast 2 people I can trust not to suck.

vasko 26 Aug 05

…If I interview 200 people I am bound to find atleast 2 people I can trust not to suck.

Joel Spolsky had an article on hiring. Basically it said, just because you hire the top 1% out of 200 people, doesn’t mean you’re getting the top 1% of ALL developers (or good people for that matter) out there.

And depending on the interviewers ability to spot good talent, your just as likely to get any one of the top 10% in that 200 than the top 1% percent. I hired a somewhat talented kid about a year ago and he just wasn’t experienced or mature enough to last.

Daimon 29 Aug 05

I can attest to the strength of developing in small teams even in a larger Fortune 500 corporate environment. Our team comprised of (1) IA- UX Lead, (1) UI Designer, and (1) Developer. The IA architected the front end, met with the business, and delivered func. specs to the developer. The UI designer worked directly from the wireframes.

Now, I will say that moving this app through the dev environments took more than (3) but the app itself was created with a small team.

arthur 07 Mar 06

does anyone know if any version of photoshop was on sale in 1990?