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.
I vividly remember a seminar in grad school at Rice University. Stu Feldman had come to visit us from Bell Labs. To this day, he is best known as the creator of make. When I asked him what made him invent it, he informed me that he was trying to make it possible for more people to work together on software. In his view, communication between people was the arbiter of how many could work together. Make, in conjunction with source control systems, simplified one area of communication so that people could work more or less independently on source files and they could all be brought together and made into a coherent whole for testing and delivery. In Feldman’s mind, before make, only 2 or 3 could productively work together. After that, he felt the number reached the 7 to 9 that human short term memory dictates as the barrier for efficient inter-personal communication.
Recently, I was talking with Peter Nickolov of 3Tera, and he echoed the sentiment. They had to build extremely complex software that virtualizes data centers, but they did it with 10 or 12 developers. After running many development organizations, Peter feels this is the optimal number for “magic” to happen, and that adding more after that will likely reduce productivity and result in a mediocre result. I quite agree with him. (BTW, I will be publishing an interview with 3Tera next week, so stay tuned–their technology is a “must-see” if you’re working on SaaS or Web 2.0 software!).
I’ve always kept the communication bottleneck and small team size ideas in mind, and found that groups take a profound dip in productivity when we get too far beyond 10 or so developers. If a product can’t then be broken up into very independent modules with extremely simple interfaces between the modules, we are stuck. The logical conclusion for development managers is they should pay inordinate sums for the very best athletes, because they will only get 10 or so working productively on a team. The other logical conclusion is to invest in improving communication in any form possible.
I like to consider the following as worthwhile communication investments:
– Wikis and other online sources that are easily searchable.
– Sufficient face time. Working separately or at home is good for productivity drives, but you have to allow enough communication face time. I like to create a frequent venue where people tell us what they’re working on, solicit feedback, and give demos. Short self-contained development milestones facilitate opportunities to communicate and apply mid-course corrections.
– Screening for great communicators at interview time. I like to run folks through a mock architecture review. I have them choose some piece of software they’re proud of and present it to the group. I think this matters a lot more than impromptu brain teasers and the other ilk one sees in some interviews.
– Focusing on team chemistry. Some managers think their job is to put as many IQ points in the room as possible. I think it is to assemble a group of people that love the idea they’re working on and love working with the team they’re on.
I’ve put all this into practice for a long time, and gotten excellent results. James Coplien wrote a paper about the amazing communication patterns that existed on my Quattro Pro team at Borland. We had 8 developers, and we recorded some of the highest productivity scores that Coplien had ever seen. As Coplien puts it when he introduces himself:
I’m one of the original Hillside pattern guys. They brought me on board because of my earlier work on C++ Idioms: C++ microarchitectures that I collected into one of the early (1991) C++ books. As I was finishing up that C++ stuff I was just starting work on organizations. It started with a study of the Borland Quattro Pro for Windows project. The ensuing DDJ article was a shot heard round the world. It was one of the foundations of SCRUM and became the foundation of the organizational patterns efforts. The organizational patterns work started appearing in 1993 and would become a foundation both of XP and the Agile movement.
I’m proud to have contributed to the early ideas that led to the more mature methodologies of Scrum, XP, and Agile programming, but it all boils down to a simple observation: It’s all about getting fewer, more talented people to work really well together as a team.
Related Articles:
Alex Iskold talks about some of these issues, and some of the newer developments like Design Patterns and Refactoring. In the end, he agrees on the fewer better developers conclusion.
Raganwald asks, “What if powerful languages and idioms only work for small teams?” Even crappy languages and idioms only produce much for small teams.