The Kitchen Drawer Problem
I’ve just had a rather enjoyable “refactoring session” with my book. At first, I had some good content sections lumped together into a catchall chapter — Working with Models. But, as the book fills out, it becomes easier to see where those sections should fit, so I was able to refactor the outline to introduce a new chapter on Encapsulation and Partitioning that will hold several of those sections.
(A small milestone today is that the book has just crept over 300 pages. It’s currently formatted to the desired width, but its length matches an 8.5x11 page, so the true length is slightly greater. It’s headed for doorstop territory.)
The refactoring of the book reminded me of a problem that I’m sure others have discovered and named, but I’ve called it the *Kitchen Drawer Problem*. It goes like this. When you have moved to a new house and are putting away your kitchen things, there is invariably one drawer with miscellaneous stuff. Even if you have dozens of drawers, each of which has a coherent grouping of things (like silverware or towels), there’s always that drawer with odd things. As you get more stuff, or drawers, or both, your organization scheme improves so things that were previously in the misc. drawer now have a natural home, but that misc. drawer never goes away (or doesn’t go away for long).
The reason I’m writing about the Kitchen Drawer Problem is that it pops up all the time in software development. We are always defining categories, whether we call those categories Objects, Modules, Components, or whatever. There are a bunch of responsibilities the system is responsible for and we, as software developers, allocate those responsibilities to categories. We try our best, but there are always some responsibilities that seem force-fit and awkward. But that’s OK; it’s natural.
As the system grows, you have an opportunity to refactor it so that responsibilities that were “in the wrong drawer” are put straight. The more “drawers” you have, the more things will have a natural home.
