GranularityMistake

Like ModularityMistake, it's where you draw the wrong boundaries around things. Here, though it's a question of decomposing your system into too small or too large fragments.

Maybe the component / framework distinction I mention on OnReuse is a simple version of the right granularity question.

Perhaps ExtremeProgramming can be thought of as talking about the right granularity in time and functionality increments, and saying it's very small.

LukeHohmann at Artima : http://www.artima.com/intv/balance3.html

Q : 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.

See also OnGranularity, DoesAbstractionScale?