Sponsored Link •
Bill Venners: In your book, Beyond Software Architecture, you write:
One of the key challenges associated with loose coupling concerns component granularity. By granularity I mean the level of work performed by a component. Loosely coupled components may be easy to understand, test, reuse, and maintain in isolation, but when they are created with too fine a granularity, creating solutions using them can be harder because you have to stitch together so many to accomplish a meaningful piece of work. Appropriate granularity is determined by the task(s) associated with the component.
How to you determine the appropriate granularity of a design?
Luke Hohmann: The appropriate granularity is a function of the number of people working on the software and the complexity of the software itself. If only two or three people are working on the project, then they can get pretty granular. As the software and team gets bigger in size, the granularity must become more abstract. What's a subsystem when only you and I are programming? We'll have an architecture, but what's a subsystem? On the other hand, if you have 300 people building the next embedded missile guidance control system, you need to design subsystems, because each subsystem will have a group of eight or ten people programming it.
When people talk about architecture, there's rarely a corresponding discussion of the granularity of the architectural metaphors, components, or descriptions that are being employed. How do I derive practical advice if I'm in a project of 6 people, 12 people, 50 people, or 100 people? I don't necessarily claim that I have the answer to that. I just know that granularity is an issue we're struggling with. I think that one reason reusable components have not always taken off as we expected is because most people get the granularity of the components wrong.
Bill Venners: How does the number of people working on the project change the granularity?
Luke Hohmann: If you're a developer on a three person team all of whom are working in the same office, you're going to inevitably have an Agile or XP-style arrangement, whether or not it's an XP shop. The granularity in that architecture will be very fine. Three people can only write so much code, and each person will only need to discuss the architecture with two other people, so you'll talk about your architecture in terms of function calls and interfaces. If you're part of a 100-person team, however, you'll have an architecture with a hierarchical structure. You'll need to be able to talk about the architecture in more abstract terms.
Bill Venners: It sounds to me like you're saying that the architecture needs to facilitate communication among the team members. If 100 developers are working on a project, the code will comprise a much vaster ocean of functionality that the developers need to talk about and think about. Therefore, the architecture will need to have subsystems—larger concepts that have a name and can be discussed at a more abstract level. You can't just talk at the granularity of classes, because there might be a million classes in that project.
Luke Hohmann: Right. One of the exercises I like to do as a consultant is to give everyone on the project a blank, 8.5x11 piece of paper and ask them to draw their architecture. I find that the members of a cohesive team will each draw a similar architecture, and the members of a dysfunctional team will draw wildly different architectures. When a client asks me for something that I know will improve the quality of work done by the team, I say, "Make sure that everyone can draw the architecture." That's different than saying, "Make sure everyone has a picture of the architecture on their desk." The team members need to be able to generate that picture from what they know in their head, and the picture they generate must be very consistent with what everyone else on the team generates. The internally generated aspect of this is the key: every individual writes code based on the context of the structure that they hold inside their head, their own concept of the architecture. If this differs you're going to have problems. In social science terms, you want to reduce ambiguity (so that things are undersood one way) and reduce equivocality (so that you're confident in the meaning that you share).
Come back Monday, April 5 for the next installment of this conversation with Luke Hohmann. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.
Luke Hohmann is author of Beyond Software Architecture: Creating and Sustaining Winning Solutions, which
is available on Amazon.com at:
Luke Hohmann is the author of Journey of the Software Professional: The Sociology of Software Development, which
is available on Amazon.com at:
The Pragmatic Programmer's home page:
A good place to start looking into Extreme Programming is: