By gst
via smoothspan.wordpress.com
Published: Oct 18 2007 / 14:12
Mark Masterson reminds us that people have been saying for a long long time in places like the Mythical Man Month book that system design integrity is best achieved through the work of a single mind. The alternative is design by committee, which dooms us to understanding by committee and all the inefficiency and waste that goes along with that approach. The avoidance of premature optimization almost always improves architectures by making them more comprehensible. Abstractions properly constrain the performance and functionality bottlenecks of a system to make them more comprehensible. Yet how often do we really focus on making architectures or code understandable? In what actionable way is that something you can measure and act on?
So far, the best answer is simply to use fewer people and live with what they can get done. It will automatically lead to simplifications and abstractions that act as firewalls. On the other side of the firewalls are initially very simple implementations, but they are placeholders. Some chief architect decided an abstraction was needed so that there would be a place to stand with a big enough lever to move the software’s world should it be necessary.



Comments
njw replied ago:
Interesting article, although the work of Belbin and Janus would suggest that even 10 is too high a number. They would suggest, and it is also my experience, that for a good team 4-6 people are the target. As you get above that, group intelligence becomes less than the average intelligence of the individuals in the group. Belbin's "Beyond the Team" has a longer discourse on this. From a practical point of view, I would suggest that software can (must?) always be broken down into modules that a few people can complete as that is a requirement of making the software maintainable.
Voters For This Link (16)
Voters Against This Link (0)