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
(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.
subscribe via RSS