This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: Jane's Rule for Loading Dishwashers
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
I've been married for nearly 14 years, and I've only recently come to understand my wife's rule for loading silverware into our dishwasher. (Married women reading this blog may roll their eyes now.) It's only recently that she explained her rule and after trying it, I came to understand why it makes the washing-and-putting away process faster.
In order to try it, of course, I had to get over the idea that what I was doing was "the right way" and open myself to the idea that there might be a better way.
As you can see in the picture above, there is a sub-divided bin for silverware in the dishwasher's lower rack. Jane's rule for putting silverware into a dishwasher is to put all the forks in one sub-bin, all the spoons in a different sub-bin, all the steak knives in one sub-bin, and so on. This doesn't happen all at once, but only as silverware gets used and then put into the dishwasher for cleaning. Or taken from the sink where it's been soaking.
The true benefit of this comes not in the "loading the dishwasher" time, since this is slightly more effort than just sticking silverware into random sub-bins. The benefit comes when it is time to unload the dishwasher, putting the clean silverware into the drawer. Now I can just grab bunches of forks from the fork sub-bin, and put them into the fork-compartment of the silverware drawer. And I can grab bunches of spoons from the spoon sub-bin, and drop them into the spoon-compartment of the drawer. Unloading the dishwasher is much more faster than it would be if I had to take individual forks out of random sub-bins.
Compare this to test-driven development. There may be a little more effort when writing code, because you are writing programmer-tests to drive writing that code. It's an "unnatural" process, like sorting silverware into sub-bins when loading the dishwasher. But the true benefit comes later in the project (possibly just minutes or hours later), when you can rely on those programmer-tests to make refactoring safer. And since you fixed bugs during TDD, you have much less work fixing bugs later when it comes time to ship your product.
I heard in an Agile Toolkit podcast of a speech by Tim Lister, that a "process" or "method" is something other than the natural way we do things. After learning and practice, it can feel natural, but it isn't the way an untrained person would do something. The speaker's example was the process of swimming. Untrained persons, thrown into deep water, either drown or dog-paddle. They try to keep their head above the water, and their feet end up deep under the water. Dog-paddling is not an efficient way to swim, but it is natural. Olympic swimmers, on the other hand, have learned an unnatural way of swimming that is very efficient. Their heads are in the water, not above it, sipping air now and then from the side, and their feet are near the surface. In the "freestyle" event, the competitors can swim in any way they like, but they all swim in very similar way because that's the most efficient way currently known. Software development and management methods like Extreme Programming or Scrum are also "unnatural" processes, but can be very efficient.
Previous Topic
