What I want to talk about this week is development - focusing on the claim that thirty men can't dig a well thirty times as fast as one man.
Experience suggests that the analogy works: doubling the project manpower usually doubles the project duration and quadruples its budget; but we need to ask ourselves why this is before we can decide whether this reflects some universal software engineering law or merely unhappy experience.
Most people would agree, I think, that small teams produce better results more quickly than large teams -and that the traditional data center driven waterfall process with its large teams and tendency to produce more meetings and paperwork than code produces the worst results of all.
Object oriented design and coding technigues have been going to solve this within five years for about twenty-five years now - because messaging offers a magic method for linking well segments dug more or less independently by each team or team member.
But it hasn't worked any better than anything else that's been widely heralded and adopted often enough that we can say it's been given a fair trial. So why not?
I think there are several divergent sets of reasons.
Most superficially, the incentives in the traditional development project work against both success and completion - meaning that hardly anybody seconded from a boring day job to an exciting, high profile, development project ever really wants to go back to that boring day job.
The most commonly cited set of reasons, of course, revolve on intra and inter team communications: the testing team focused on the wrong issues, the coding team didn't understand the specs, the specifications team didn't understand the limitations of the development environment and budget, the users misunderstood most of the UML (or the modelling religion of your choice) nomenclature and symbology the specs people claimed were being used to define the detailed requirements, and, of course, the steering committee thought it was managing a completely different project.
Basically the argument is that the communications burden on a project goes up roughly as 2 to the nth, where n is the number of players involved; and the reality is that there's a lot of truth to this - certainly the number of opportunities for mis-communication goes up exponentially with team size.
The trouble with this diagnosis is that object oriented methods address precisely this concern and by their failure illustrate its explanatory inadequacy.
So what's the most basic problem of all? I think it's simply this: the programming language appropriate for a particular application is the highest level language in which the requirements can be fully and completely expressed.
In other words it's the separation of coding from requirements analysis and design that's at the root of the problem and it's their integration, not team size, that has the greatest explanatory power for the relative success of small teams.
To see this, let me suggest another analogy: write down the specifications needed for an artist to draw a particular face the artist has never seen, pass that specification to a half dozen artists, and compare the results.
If you do this without woking one on one with each artist as the work is being done and without including a drawing or photograph in your spec kit, no one will get close - because the drawing you want is the minimum possible precise specification for itself.
Or, in the original context, any requirements specification that's sufficiently precise to be turned into code without forcing the coder to make judgement calls about how things are supposed to work is mechanically equivelent to code. Or, to put it yet another way: the programming language appropriate for a particular application is the highest level language in which the requirements can be fully and completely expressed.