Cutting a Monster Project Down to a Manageable Size
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Writing software is a complicated undertaking. As every programmer knows, it's counterproductive to try to think through a big program in one sitting; instead, you have to break the software into modules. At any given time, you either think about how the modules work together at the very highest level of abstraction, or you think about the inner workings of a single module. You never think about the whole problem in all its detail.
Fortunately, programming languages such as C or Pascal help engineers break a problem into components. These languages and their accompanying methodologies allow you to define self-contained and reusable functions and procedures, which you can view as "black boxes" that you put together to form the big solution. At any given time, you either think about how the black boxes work together at the highest level, or you think about the inner workings of a single black box.
Thanks to object-oriented programming languages and methodologies, we have still-better ways of breaking up problems. We can separate a problem into groups of objects, each of which is a set of data and operations on that data. Again, the smaller building blocks can be considered black boxes that can be put together to form the big solution.
In software engineering, when breaking down a project into smaller pieces, an important consideration is that each module perform a clear function and have clear inputs and outputs. Once a module is written, you should be able to think of it abstractly, without having to remember how it was implemented.
This same process of breaking up large problems into smaller bits is a powerful way of working on big personal goals. Instead of thinking about the monster project as a whole, break the scary thing into pieces that you can put together to form a solution. Once you figure out how to decompose the problem, and you decide what the building blocks should look like at the highest level, you can focus on each piece at a time in succession.
But what are the best ways to find the optimal building blocks? Let's look at two areas of cognitive psychology for some clues.
Breaking a Task into 'Chunks'
The first place to look is in the area of research around how we group similar items, so that we can think of them at a higher level of abstraction as a single unit. In the 1950s, psychologist George Miller wrote a famous paper called "The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information," which shed light on human capacity to remember things—whether those things are audio or visual data, or abstract ideas. Miller observed that we're able to remember between 5 and 9 (7 plus or minus 2) "chunks"—sets of items with semantic or perceptual relationships. For example, words with similar meanings might be put into one chunk. Alternatively, words that rhyme might be grouped together. [1]
Miller demonstrated that the way in which we group items makes a big difference in how easily we think of the package as a black box. This idea can be extended to work projects. If we can cut down a project into meaningful components, it's relatively easy to piece the components together and conceptualize the larger solution. The key is to make sure that the components are meaningful.
The second area of cognitive psychology is the research around how we group tasks into working spheres. Studies suggest that when we multitask between activities within a working sphere, multitasking is productive. When the related items compete for our attention, moving from one such item to another actually helps us see the first item in a different light and complete the work on that first item more quickly.
On the other hand, when we multitask between activities that are not related—that is, the activities are not in the same working sphere—the drop in efficiency is dramatic. It takes much longer to complete any one of the tasks we're juggling, when those tasks are unrelated.
This research on working spheres reinforces the value of meaningfully grouping work tasks. When you break up a project into work objects, make sure that the tasks within each object constitute a working sphere—a related set of activities among which you can switch. [2]
The key finding here is that when we break up a large project into smaller units, those units should be manageable amounts of work, and they should represent something meaningful to the overall solution. They should be abstract building blocks that can be put together to solve the big problem.
One way to help remember how to cut up a large goal into a manageable set of components is to think of each component using the acronym CRUMBB (pronounced "crumb"), which stands for "Clearly Realizable Units that are Meaningful Building Blocks." Most people already break big tasks into clearly realizable units, but very few think to make sure that those components are also meaningful building blocks.
Four Steps for Breaking Up a Monster Project
Next time you're up against a big project, do yourself a favor. Instead of allowing yourself to become overwhelmed, take these four steps:
- Consider the big goal from two angles.
- Cut your big goal down into smaller pieces.
- Concentrate on one CRUMBB at a time.
- Reward yourself for achieving each small goal.
Now let's examine these steps in a little more detail.
Step 1: Consider the Big Goal from Two Angles
First, take the inside view—that is, look at the problem from your subjective standpoint. Think of the large components of the project, make a rough estimation of how much effort is required to implement each piece, and then imagine how the different parts will work together to meet the larger goal.
Second, take the outside view—that is, look at the problem from an objective standpoint. Ask other people how they tackled similar problems. Find out how much effort it required, and try to gain an understanding of the kinds of issues they faced in their comparable projects.
Based on these two different views, you should be able to come up with a pretty good estimate of how much work is required, and you should be able to find natural ways of breaking the project into smaller pieces.
Step 2: Cut Your Big Goal Down into Smaller Pieces
Not only should you cut the project down into smaller pieces, you should make sure that each of those pieces represents a meaningful component of the overall problem. Break the project down into "Clearly Realizable Units that are Meaningful Building Blocks." Each unit should be something you can complete, and it should be something that can be viewed from the outside as a black box.
Step 3: Concentrate on One CRUMBB at a Time
You might work on more than one CRUMBB in a given day, but you should try to work on just one at a time. As we know from research into multitasking within a working sphere, you may be able to switch between related activities efficiently, but when you multitask outside the working sphere, efficiency drops. The best CRUMBBs make up a working sphere, or a set of related tasks.
Step 4: Reward Yourself for Achieving Each Small Goal
After you finish a CRUMBB, take a moment to appreciate what you did. At minimum, step away from your desk for a little while to think about something else, making a clean break before you start working on the next CRUMBB.
Summary
Computer programming has given us powerful problem-solving techniques that help us break large tasks into small, manageable subtasks. Cognitive psychology has shown us that the more meaningful those subtasks are to the overall project, the more efficiently we work on each piece.
By breaking up monster projects into clearly realizable units that are meaningful building blocks, you'll get a lot more done. What's more, you'll gain in satisfaction, because you'll keep a cool head as you work the problem one small piece at a time.
References
[1] George A. Miller, "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information," Psychological Review Volume 63, No. 2 (1956), pp. 81–97.
[2] Gloria Mark, Victor M. Gonzalez, and Justin Harris. "No Task Left Behind? Examining the Nature of Fragmented Work," CHI 2005: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (2005), pp. 321–330.