Why scale teams?
There are a lot of tools (Java, use case diagrams, etc.) that are chosen because they can scale software development so that a large team of people can work on the same code. Reg Braithwaite asks why the common wisdom is to scale the team up in numbers, rather than up in productivity:
If everything we know about teams suggests that smaller teams have the greatest productivity, isn’t it a valid choice to invest heavily in tools and processes that are specifically tuned to maximizing the productivity of small teams?
Nov 23 2007
1:43 pm
From the MBA’s perspective scale represents power and safety. Brooks has definitively disproved the actual throughput of scaled development teams (though most ignore his findings). Similarly, safety is an arbitrary measure, as redundancy is only one way of mitigating development risks.
Most of the business minds I’ve worked with have fundamentally misunderstood how to scale software development. It’s a counterintuitive leap from other industries (like farming or manufacturing), and is a voodoo science to the untrained eye.
Engineering scales similarly to development in a sense. You don’t add thousands of engineers to bridge building problems, you have more robust methods, and combined statistical measures. Complex engineering problems (Boeing, for example), break the engineering into small teams, and reuse a large body of statistical and material knowledge. But engineering has physical obvious coupling points (software is all invisible, non-physical).
Nov 23 2007
7:24 pm
I imagine that engineering teams with difficult problems use computer assistance and modeling techniques to make their jobs easier, the way programmers can use more advanced tools and languages.
Trackback Natassia Malthe
Jan 15 2008
1:46 pm
Natassia Malthe…
Man i love reading your blog, interesting posts !…