The Tyranny of the "To Do" List


We create lists to help us prioritize tasks and stay on schedule. Sometimes those lists help us accomplish those tasks faster. Sometimes those lists simply chain us to an archaic way of doing things. Having a "To Do" list is a good thing if you don't let it prevent you from thinking outside the box. In this column, Elisabeth explains why the agenda items that don't make the list can often be some of the most important.

I have a "To Do" list. Actually, I have several. I have Web site update "To Do" lists and "Client To Do" lists and "Writing To Do" lists. But I digress.

Every time I make a commitment, I try to remember to put an item onto the appropriate "To Do" list. My usual habit is to remove items from the list only once they are complete. And that means that my "To Do" list can get very backed up. I often struggle with the feeling that I must complete everything on my "To Do" list, an impossible task. Worse, I sometimes feel required to finish certain onerous "To Do" list items before I move on to the more interesting tasks on my plate. Some of the onerous tasks may be less strategically important than the fun ones, but they're on my "To Do" list, so I feel they must be done. The end result in some cases is that neither the onerous nor the fun tasks get done. I'm stuck.

In the worst cases, I've had to throw out that "To Do" list and start over. This is not ideal—I'm throwing out the good with the bad. But sometimes it's the only way to get myself unstuck. A better approach is to comb through the "To Do" list, plucking out those items that truly still need to be done and then tossing the rest. But by the time I get stuck, I'm incapable of doing even this kind of weeding. The whole list has to go.

When I let myself get stuck on a handful of "To Do" list items, I am suffering from the tyranny of the "To Do" list. I am allowing my life to be run by line items stored in my planner. That just doesn't work. I can't allow my "To Do" list to run the show. Yet I see the same kind of "To Do" list tyranny happen in some test departments. "We have the test in our suite, we have to run it," they say. "No, we can't add more tests. No, we can't improvise. This test is here; it must be run. It leaves no time for any other testing." What a sad situation.

There are an infinite number of tests we can run. Of those, some are more likely to yield interesting information than others. In testing, we're after the interesting information. Unfortunately, some test suites seem specifically designed to not find out anything interesting. The documented tests might have been interesting two years ago, but they yield no new information now. Wouldn't it be a shame to miss a serious bug because we're too busy running the planned tests?

Think it can't happen? I've seen it. For that matter, I've done it. I've seen entire departments slog through the tests cases in their documented test suites because they were "supposed to," all the while bemoaning the fact that they didn't have time to do the interesting testing. In one such organization, one tester argued with her manager for the freedom to run some unplanned tests. "No," said her manager. "If you think it's important enough to run, it's important enough to document. Put it in the test case database, and then you can run it." Mindful of the time these updates were taking, the tester only added those tests she thought were most critical.

As a result she nearly missed a showstopping bug. Fortunately for her project, she found it just in time—because she deviated from her test suite while testing a bug fix. Her manager finally relented. He gave her a little time to do exploratory testing. He wondered if she could she put an item in the test case database called "Exploratory Testing," though. This is the problem with following "To Do" lists.

About the author

Elisabeth Hendrickson's picture Elisabeth Hendrickson

The founder and president of Quality Tree Software, Inc., Elisabeth Hendrickson wrote her first line of code in 1980. Moments later, she found her first bug. Since then Elisabeth has held positions as a tester, developer, manager, and quality engineering director in companies ranging from small startups to multi-national enterprises. A member of the agile community since 2003, Elisabeth has served on the board of directors of the Agile Alliance and is a co-organizer of the Agile Alliance Functional Testing Tools program. She now splits her time between teaching, speaking, writing, and working on agile teams with test-infected programmers who value her obsession with testing. Elisabeth blogs at and can be found on Twitter as @testobsessed.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!