No Such Thing As Size

I shall offer the probably controversial and possibly wrong assertion that there is no measure of the "size" of a project, or problem. I shall take function points on as a second part to the discussion. The position I wish to break is the thinking that number of people on the project is related to problem size.

I wish I knew how many people were originally on the ChryslerComprehensiveCompensation project (fill in the number here: 40, I think [kb]), then I could offer that as an example: "we thought the project was a 30 person, 2-year problem, but it turned out after they couldn't deliver it, that it was 'only' a 6-person, 1-year project."

The moral I wish to draw is that when talking about MinimalMethodologies, we can talk about the number of people ON the project, but we can't talk about the number of people NEEDED ON the project. I.e., we can't talk about the problem size in terms of number of people. This means that when critiquing a methodology proposal in the Crystal-methodology set, we cannot establish where on the x-axis (number of people to coordinate) we NEED to be, only where we CHOOSE to be.

This is early thinking and I probably don't know what I am really trying to express yet.

AlistairCockburn

Have you read Brooks' MythicalManMonth? The title seems to make a similar point. He discusses how costs of communication change with team size, and quotes a 1968 survey in which average programmer productivity varied by a factor of 10. Essential reading. -- DaveHarris

I think I see where Alistair's coming from. To go with a ChauncyGardener analogy, there are two good ways to kill a plant: you can flood it or you can parch it. If you flood it then it rots. If you parch it then it withers. It doesn't matter that you want to grow your acorn into a mighty oak (fill the problem space) - if you don't provide just the right amount of water at the right time, you'll kill it.

Developers are water for a development. They flow through the thing helping it grow - they're a solvent for it. Too many and the thing rots - politics and divergence and bad ornamentation happen. Too few and it withers - better resourced developments grow to fill the problem space, and its market (its soil) blows away.

So I'm suggesting that it's not the number of developers or the number of requirements that characterize a development; it's the potential for growth of the solution and how closely you meet its inherent resourcing requirements.

But how long will it take you to satisfy the requirements? Well, what kind of plant are you growing? Some plants can't grow above knee-high, but they do that in a week. Others grow up into the clouds, but take centuries to do it. If you can characterize the solution space - understand the way various tools and various kinds of developers have interacted in the past to satisfy similar requirements - only then do you have some hope of making valid estimates about how long your particular solution will take to bear fruit - if you garden it right. --PeterMerel