Beans, Ping-Pong Balls, and Priorities

Not too long ago I found my wife placing ping-pong balls followed by beans into a canning jar. After briefly trying to reason about what she might be doing, I asked her.  She explained that she was preparing a lesson about priorities for the children in her church primary class, and then elaborated.

The canning jar represents our day.  Each day certain important things need to be completed.  These are represented by ping-pong balls with a label summarizing the task.  The beans represent other things that occupy or time throughout the day. The bean could represent inconsequential, such as spending a few minutes watching the news, or something necessary, such as eating a healthful meal.

Daily Organization

How should the day best be organized to accomplish all necessary tasks?

Possibility 1 - tackle the small tasks first.


Each small task is accomplished and each bean is placed in the jar until none remain.  Next, the larger tasks are attempted.  But, before long, there isn't any more room and it becomes impossible to accomplish all of the larger and more important tasks.

Possibility 2 - tackle the priority tasks first.

As each task is accomplished, the representative ping-pong ball is placed in the jar. Next, the remaining smaller tasks are completed and the beans placed into the jar.  These beans flow easily around the ping-pong balls, and the jar is quickly filled.

Priorities & Analogy

Which of our daily tasks are ping-pong balls, and which are beans?  The following are on my priority (ping-pong ball) list:

• Test-Driven Development (TDD)
• Pair Programming
• Refactoring
• Testing
• User Interface Design / User Interaction Design
• Self-Improvement

Bean Accrual Patterns

Of course, it’s likely quite obvious that if we fill our day with little inconsequential things, we’ll eventually run out of time to accomplish important,  priority tasks.  So, why the comparison?

We accrue beans in two different ways.  First, when we choose to work on tasks that aren’t truly important or become distracted with tasks not pertinent to our goals and priority tasks.  Good time management skills like those taught in the Pomodoro Technique can aid much in this regard.

The second accrual pattern is not a time management issue, rather, it’s a result of less-than-ideal software or code quality, which I’ll define as not as good as it could have been.

When developing using TDD, tests come first.  Of course, I’m not going to purposefully create an API for myself that’s difficult to test.  But, when I don’t do TDD, it will inevitably happen.  I’ll end up doing something that makes it harder to test and not as good as it could have been. My bean has now been created.

But in reality, it’s likely worse than that.  I didn’t create just one bean, rather, I created many beans:

• A turgid or fragile design
• A hard to test design
• A manual testing requirement
• Increased cognitive load
• Decreased understanding of requirements
• (Likely) increased coupling

Without TDD, as soon as I go to test that piece of software, it’s going to take longer because I will have missed something, making it harder to test.  As soon as a requirement changes, I’ll need to manually re-test the necessary pieces.When a change request comes through a couple of months down the road, I won’t have good, concise examples of how to use that code, and it will take me longer that it could have.

Yes, there is a tax, of sorts, associated with TDD, but what about the ROI?  Unless you’re absolutely sure it’s negative, I recommend it.  Oh, and don’t forget, you can’t measure ROI one minute after investing, it’s a long-term investment.

Other Beans

Throughout the years that I've been programming, I've seen days and even weeks fill with beans:

• When I don't do TDD, my code is not as good as it could have been.
• When I don't do pair programming, I’ll miss something important or do something dumb
• When I don't adequately refactor, my design degrades
• When I don't sufficiently test, either before, during, or after coding, I'll end up rewriting some aspect of my design

A few beans don't matter.  Nobody will notice... and it's easy to justify just a few beans.  The problem comes when you've amassed so many you now have a collection.  This is technical debt.

Bean Removal

Technical debt must be paid down before the interest accrues too rapidly.  Each day, beans, our daily impediments, must be removed, and we must remove more than we create each day; we must shovel our way out.  Unfortunately we can't usually start with a big shovel, we usually need to start with a hand trowel, slowly removing the encrusted dirt and debris. Eventually, we'll be able fit in one more ping-pong sized, important task. And then two... and then three. Given enough persistence, you can turn that brown field green.