📄 hundredpersonproject.html
字号:
<head><title>Hundred Person Project</title></head><body><h1><img src="logo.gif"> Hundred Person Project</h1><em>The purpose of this little thought experiment was to express in an amusing way the notion that projects with large staffs may not get any more work done than projects with small staffs. Large projects (as opposed to large problems, with thanks to Alistair for the notion) do seem to have very high overhead. This would suggest that the same amount of actual development could be done by a smaller project in the same amount of time.</em>
<p><hr>
<a href="http://c2.com/cgi/wiki?ChetHendrickson">ChetHendrickson</a> and I were talking about this today while preparing our Smalltalk Solutions talk. Chet, fix this to be better if you like ...
<p>Imagine a hundred person project, scheduled for a year, or 200,000 person hours. Of the 100 people on the project, how many are actually programmers? We guess maybe 40. So there will be 80,000 programmer hours.
<p>How much programming will these programmers actually do? (In XP terms, what is their <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a>?) In a conventional project,they clearly spend the bulk of their time preparing for meetings, attending meetings,writing documents, writing comments, and reading documents to figure out how to write their code. We think their <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a> is about ten, that is, in a typical week, they actually spend a half-day coding.
<p><em><a href="http://c2.com/cgi/wiki?AlistairCockburn">AlistairCockburn</a> asserts that the <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a> couldn't possibly be that bad, and has visited projects that report more programming than that by far. 30 or 40 hours in a week, even. If t this is true, then the reasoning below is not valid.</em>
<p><strong>Don't all programmers REPORT 40 or more hours of programming a week?</strong>
<p>Therefore there are 8,000 actual hours of programming, per year, done in a 100-person project.
<p><em>Alistair believes that we can't convert our measures of actual development time to real time into estimates of how long development will take. However, that's what we do all the time. There is some communication mismatch here, I believe. If we can't multiply programming time times <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a> to get elapsed time task estimates, then what's below isn't valid.</em>
<p>Our XP developers have load factors of 2 to 2.5 by actual measure. Therefore you can get 8,000 hours of programming done in 20,000 real hours. That's ten people, one year.
<p>A <a href="HundredPersonProject.html">HundredPersonProject</a> is a ten-person project, with overhead. Doctor, it hurts when I do this. --<a href="RonJeffries.html">RonJeffries</a>
<p><hr>
I like the math, but I'd like you to try it another way. What if the question was not how much programming you get done, but how much you learn (this fits with HowardBaetjer<a href="http://c2.com/cgi/wiki?edit=HowardBaetjer">?</a>'s <a href="http://c2.com/cgi/wiki?ProgrammingIsSocialLearning">ProgrammingIsSocialLearning</a> idea)? How fast can a 100-person society learn compared to a 10-person society? --<a href="KentBeck.html">KentBeck</a>
<p>See LargeProjectLearning<a href="http://c2.com/cgi/wiki?edit=LargeProjectLearning">?</a>. (And fill it in ... I can't, yet.)
<hr>
<em>(Indented stuff is InterpolatedComments<a href="http://c2.com/cgi/wiki?edit=InterpolatedComments">?</a>. I guessed the attributions. I inserted new ones because I think every change of author needs a fresh attribution, to emphasis that change. I removed some formatting. This is something of an experiment, to see if it is any clearer. -- <a href="http://c2.com/cgi/wiki?DaveHarris">DaveHarris</a>)</em>
<p>Suppose the project is to produce a Smalltalk framework for other programmers to use. Or suppose you are in the position of Sun, having to create a raft of libraries for a new language or a new operating system. Say you have 10 programmers on the project but 100,000s are going to be working with the code you produce. How do you deal with that?
<p>My guess is that you see the code as the product, and you do produce things like documentation (and maybe even comments?) although it's for the external client programmers rather than for the internal team. -- <a href="http://c2.com/cgi/wiki?DaveHarris">DaveHarris</a>
<p><UL><li> The product is whatever the customer wants. Certainly we'll do a manual when we need one. And if comments were useful (as in your scenario they might be) we would do them. --<a href="RonJeffries.html">RonJeffries</a>
<p></UL>A flip side of the question is, how do XP teams deal with the 3rd party frameworks that they buy in? Say you've got this GUI library full of neat widgets. Hey, at the end of the first 3 week iteration, 95% of the widgets are not being used! <a href="http://c2.com/cgi/wiki?YouDontNeedEm">YouDontNeedEm</a>. Delete the source. -- <a href="http://c2.com/cgi/wiki?DaveHarris">DaveHarris</a>
<p><UL><li> Of course there is a difference between how we treat the code we write: we refactor it, pat it, prick it, mark it with a C[3]; and code we buy. We don't refactor the base image, we extend it. Ditto other 3rd party code. Reasons available on request, but I suspect they're obvious to us all. --<a href="RonJeffries.html">RonJeffries</a>
<p><li> Would it make sense to split a group of 20 into two groups of 10, with each group treating the other as "3rd party" and/or client? Is this the way to scale XP? -- <a href="http://c2.com/cgi/wiki?DaveHarris">DaveHarris</a>
<p><li> <em>The difference is that 3rd party code comes complete and ready to run. If both sides are evolving rapidly, the interface might (read will) become the problem. My customer (the other team) needs things now. In XP, we are the other team, and we fix the other class if it needs it. So this would be a big deviation from the XP "philosophy", I suspect. --<a href="RonJeffries.html">RonJeffries</a></em>
<p></UL>By the way, I'm putting forward the (old) idea that the way to deal with a 100 person project is to split it into 10 10 person projects.
-- <a href="http://c2.com/cgi/wiki?DaveHarris">DaveHarris</a>
<p><em>No, the way to deal with a 100 person project is to fire the bottom 90% of the staff.</em>
<hr>
I wonder about that also. Is XP suitable for production software as opposed to inhouse developmennt? Seems like you need clients there (when you develop code for retail sale), or do you <a href="http://c2.com/cgi/wiki?DogFood">DogFood</a> it yourself? -- <a href="http://c2.com/cgi/wiki?MichaelFeathers">MichaelFeathers</a>
<p><em><a href="http://c2.com/cgi/wiki?ClientPresence">ClientPresence</a> is an important part of XP. It replaces huge requirements documents, with their large cost in time and clarity, with presence of someone who actually knows and can decide. This is consistent with Baetjer's notion that software development is very much about mutually discovering, with the client, what is needed.. --<a href="RonJeffries.html">RonJeffries</a></em>
<p>I have more than a dozen years experience in packaged business software. It never worked unless we had real clients that were really available almost any time for consultation. Only difference is we usually had more than one flavor of real client, which has its own problems - they seldom agree. --Bob Haugen
<hr>
See <a href="http://c2.com/cgi/wiki?IdealProgrammingTime">IdealProgrammingTime</a> and <a href="http://c2.com/cgi/wiki?XpProductivityMeasurementProblem">XpProductivityMeasurementProblem</a>.
<hr>
I have seen two different groups that did the same thing in Smalltalk.
Both were interested in making a framework and products that used it.
Both the frameworks and the products were similar, at least they solved
the same problems.
One project started with two gurus who gradually grew the core group
to five or six, but added on dozens more to make applications. They
spent a lot of their time teaching people Smalltalk. The other started
out as a 100 person project, with 15-20 people devoted to the core
frameworks and the rest to building applications. Although both groups
had plenty of problems, the first group was more successful. The people
I talked to on the second group said they would have been done long
before if they had just done it with their best 15 people instead of
with the entire group.
<p>One problem is that it is hard to get a large group of really good people,
so the average experience and skill goes down on large projects. Also,
large groups require several managers, and they can start having political
battles with each other. In a large group, some people are sure to leave
before the project is over, and that slows things down a lot. If someone
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -