When you go shopping, you probably break down the task into steps something like:
- Drive to the grocery store
- Purchase items
- Try all the free samples
- Go home
- Put everything away
If you think about task #1 a little more you can most certainly break it down further into individual steps — it’s actually quite complicated if you think about it for a bit.
But you don’t because that would be silly. You get in your car and go places every day so why would you bother to decompose the task further. In fact, by that argument, tasks #1 through #4 are probably too much. If you actually think about it consciously at all, it’s probably more like:
- Get groceries
And so it is with software design.
When we decompose problems for purposes of estimating, implementing, or doing detailed design work, we tend to stop at a granularity below which decomposing adds no value to us. We have enough experience (and/or confidence) to proceed without further breaking of things into smaller things. We’ve been here before and know what needs to be done going forward.
But the thing to keep in mind is that the particular level of granularity we are comfortable with is based on our experience in the context at hand. If we’ve written lots of web page apps, our confidence will be high with a gross level of granularity when we are dealing with web page apps. If our next project is writing a graphics-intensive on-line game, we’ll probably need to break things down into finer-grained pieces.
A corollary here is that for a given problem in a given context, the level of granularity chosen by two different developers will likely be quite different, unless their backgrounds are astoundingly uniform. So a high-level design decomposition written by one will not have the same meaning to the other. In fact, in a worse case, it won’t even be comprehensible!
Consider a web-page developer doing a high-level decomposition of a new site, where the decomposition is then handed off to a less-experienced (in that specific domain) developer. Will the decomposition be useful? Probably not very, because the experienced developer will have stopped breaking things down at their point of comfort. But the less-experienced developer will be at a loss at that same point.
This can go the other way too: a less-experienced developer breaks a design down into dizzying detail and the project is handed to a more-experienced (everybody say it with me: in the given context) developer. Will the decomposition be useful? Again, probably not. In a best case it will simply be far too detailed and have cost a good deal of unnecessary effort for the first developer. In the worst, the more-experienced developer will disregard it, sketch out a far simpler structure on a napkin, and get on with the work.
I believe this decomposition-mismatch is why the practice of having one group do design and then hand it off to another group for implementation is fundamentally inefficient and flawed. I think it’s also why using estimates for a project given by one person/group when the work is actually done by a different person/group is foolish, and this is especially true if the party doing the estimating is not technically astute in the given problem area.
How does this observation help us? Well, for one thing, any time you are working with someone else, or trying to explain or understand a design, keep in mind the granularity issue and either adjust yours or ask the other party to adjust theirs as appropriate. What is needed is to match the level of granularity of the presenter to the audience to ensure that the right information is actually communicated.
The alternatives are confusion or boredom, and I think we’ve got enough of both already…