Just as ideas of software architectures can be expressed with pattern language, so can the structures of organizations and teams. This section covers some of the more thought-provoking organizational patterns I have come across.
It’s been long recognized that, when building software, certain things “work” and others don’t. Before we discuss some team patterns, lets look at a few patterns that are known to do us disservice.
Noticeable Diseconomies of Scale arise from increasing the size of programming teams. It has been said that, for any given task, the best results will arise if the task is done by one person, second best results will arise from two people, third-best by three, and so on. Why so? Mostly because of the burden of communications: As the number of programmers increases, the number of pairwise intercommunication pathways between individuals increases according to the following formula:
P=n(n-1)/2
Here’s below is a table of this function. The conclusion is clear: Increasing the size of a team is expensive in unexpected ways. For example, boosting a programming team from 2 to 3 triples the number of intercommunication pathways. Each pathway must be managed, and as the number of pathways increases, so does the cost of coordination and, ultimately, mistakes. Consider that even in the best of teams you never get perfect communications…
| Members | Pathways |
|---|---|
| n |
n(n-1)/2 |
| 1 |
0 |
| 2 |
1 |
| 3 |
3 |
| 4 |
6 |
| 5 |
10 |
| 6 |
15 |
The increasing burden makes good intuitive sense too. Coordinating a many people, giving them all a sense of unified purpose, and making sure they all work in a coordinated fashion is difficult under most circumstances. On the other hand, a single properly oriented person can be a self-sufficient unit.
We must also bear in mind the notable Productivity Discrepancy among programmers. Estimates vary, but it is apparent that the productivity of the best programmers is between 5 and twenty times greater than that of poor programmers. This doesn’t mean that a good programmer writes twenty times more code! It means that the life-cycle costs (development, testing, and lifetime maintenance) of the code from the best programmers is between a fifth and a twentieth of that coming from a poor programmer.
All these factors combine to form what’s known as the Mythical Man Month which embodies the notion that resources do not combine in a linear fashion. This supports the experience that adding resources to a project usually doesn’t help and quite often makes the problem worse. As described above, resources in software projects have complex interrelationships leading to counterintuitive results when increasing a project’s resources in response to a slipping schedule.
What, then, are some workable patterns for organizations and teams? Here I outline a few, and there are surely many more we will talk about. Most patterns focus on finding an optimal size for individual teams, and to reduce the number of communication pathways and functional interdependencies between teams.
It’s clear that select individuals can build entire projects by themselves. Our industry has many examples of successful single-person achievements. In the FoxPro world, utilities and frameworks like GENSCRNX, GENMENUX, GENREPOX, Tom Rettig’s Office, GPLIB, Codebook 2.0-2.6 and others are examples of single-mind products. Countless successful custom applications are the product of a single developer or a very small team with a dominant leader.
Given that organization size affects the product in a non-linear manner – communications overhead increases quadratically with team size while the “horsepower” increases linearly (or less so) as new people (some less talented than others) are added to the team.
A one-man team is most certainly a natural example of “critical mass”. The problem is, a single person can’t create large software systems. What, then, are subsequent critical mass points?
A natural extension of the Solo Virtuoso pattern is to increment the team by one and work as a pair. After all, two heads are better than one, right? Not necessarily. Several forces come into play here, the most important being (obviously) the compatibility of the participants.
We’ll discuss patterns of pair development in the session.
In larger projects, an important quality is whatever is everyone’s responsibility is, in the end, no one’s responsibility. Also, it’s often difficult to navigate and change another person’s code, especially if much design knowledge is buried therein.
A reasonably effective solution is to assign ownership of specific classes to individuals, and thus assign quasi-permanent custody of its evolution and maintenance. But doing so is not without problems: it’s difficult to assign even loads with code ownership, and the resulting quality of the code varies with the quality of its owner. Tunnel vision can result from narrow ownership. Also, the organization needs to limit the turnover of the development team, something that may not be possible since each segment of code ownership has offers different levels of challenge, interest, and hence potential for satisfaction.
We’ll develop this further in the session.
In his classic book from the 1970’s called The Mythical Man Month, Frederick Brooks describes a provocative pattern (first proposed by Harlan Mills) for a 10-person development team. This arises from the fact that large software projects cannot possibly be written by one man or by a single small team.
The proposed notion is to split the project into small-team sized chunks, with an eye on optimizing both the inter- and intra-team communications.
Here is a diagram of the team structure he proposes:
Here is an overview of the roles in this team:
The surgeon is the chief programmer and the el-presidente of the whole team. He produces all the specifications, codes the entire system the team is responsible for, tests it, and drafts its supporting documentation.
The copilot is the surgeon’s assistant. His main purpose is to share in the thinking about design issues – to serve as a sounding board, as it were. The copilot represents the team in meetings with other teams. He knows the code intimately, and serves as insurance in case of disaster to the surgeon.
The toolsmith supports the surgeon and builds specialized utilities
and tools as may be required by his surgeon. Each team has its dedicated toolsmith
in addition to any central services provided by the rest of the project infrastructure.
The tester is responsible for maintaining test cases for testing the surgeon’s work as he writes it. He is both an adversary who devises test cases to measure against the formal specs and devises test data to be used in debugging.
The language lawyer, which can serve several surgeons, I a widely consulted specialist who delights in the mastery of the intricacies of the programming languages and the operating systems upon which the software must perform.
The administrator handles money, people, space, and machines. The surgeon is the ultimate boss, with the last word on all these issues, but the day to day management of the issues and interfacing with the administrative machinery of the project is the role of a professional administrator. One administrator may serve more than one team.
The editor edits and revises the documentation as drafted or dictated by the surgeon and oversees the mechanics of its production.
The program clerk, trained as a secretary, is responsible for maintaining all the machine-readable and human-readable technical records generated by the team. All the filing and indexing is the responsibility of the program clerk.
The secretaries handle the project correspondence and non-project files.
Whether of not the surgical team structure works for you conceptually, it’s interesting to note the very high ratio of supporters to coders in this structure. I reckon the ratio is 2 or 3 to 1 depending on how many members support multiple teams. This ratio isn’t unusual as evidenced by the recent works of Steve McConnell (Code Complete and Debugging the Development Process) from Microsoft press.
Does your company have a 2:1 supporter to developer ratio? Probably not. It probably should.
Alexander,C., et al. A Pattern Language. New York: Oxford University Press, 1977. ISBN 0-19-501919-9
Alexander,C., et al. A Timeless Way of Building. New York: Oxford University Press, 1978.
Black, S. (1995) Pattern Implementation in VFP, European Visual FoxPro Developers Conference '95 session notes, E-PATT, Frankfurt, Germany. And also: GLGDW '95 session notes, #30, Milwaukee, WI.
Brooks, F, (1975 and 1995) The Mythical Man Month.. Reading, MA. Addison Wesley. ISBN 0-201-83595-9.
Buschman, F, and Meunier, R (1995) A System of Patterns. Chapter 17 (p.325) in a compilation work by Coplien, J, and Schmidt, D (1995) Pattern Languages of Program Design. Reading, MA. Addison Wesley. ISBN 0-201-60734-4.
Coad P, North, D, and Mayfield, M, (1995) Object Models: Strategies, Patterns, and Applications. Prentice Hall. ISBN 0-13-108614-6. Also a helpfile: STPTHLP.ZIP in CIS.CaseForum, Lib 3
Coplien, J. Advanced C++ Programming Styles and Idioms. Reading, MA: Addison Wesley, 1992.
Coplien, J, and Schmidt, D (1995) Pattern Languages of Program Design. Reading, MA. Addison Wesley. ISBN 0-201-60734-4.
Gamma, E., Helm, Observations on Observer, Dr. Dobb’s Sourcebook, September/October 1995.
Gamma, E., Helm, R., Johnson, R, and Vlissides, J. (1994) Design Patterns, Elements of Object Oriented Software. Reading, MA. Addison Wesley. ISBN 0-201-63361-2
Hay, D (1995) Data Model Patterns: Conventions of Thought. Dorset House.
Helm,R, and Gamma, E. The Courrier Pattern. Dr .Dobb's Sourcebook Jan/Feb 1996. Miller Friedman Inc, San Francisco.
Juancarlo Anez. (1995) A Perfect Fit. Windows Tech Journal, September 1995, Oakley Publishing Company, Springfield OR.
Pree, W (1995) Design Patterns for Object Oriented Development. Reading, MA. Addison Wesley and ACM press. ISBN 0-201-42294-8.
Rohnert, Hans, PLOP 96 Conference Proceedings, Addison Wesley (1996)
Vlissides, John, Seven Habits of Successful Pattern Writers, C++ Report, Vol 7 no 9, November-December 1995, SIGS publications, New York NY.
Some interesting internet sites:
http://www/state.sd.us/people/colin/fox_page.htm
The Cunningham and Cunningham inc homepage, http://c2.com has a description of pattern history, a description of the Portland pattern form, guidelines for writing patterns in Alexander's style, and several patterns and pattern languages and links to other sites.
The patterns homepage: http://st-www.cs.uiuc.edu/users/patterns/patterns.html Maintained by Richard Helm.
Conferences:
PLOP ’96, “Pattern Languages or Programs”, Sept 4-6 1996 in Allerton Park Il. http://www.cpl.uiuc.edu/~plop/
|
|