I got 99 problems, but that's better than one
June 13, 2020
Este ensayo también está disponible en español.
Breaking up big problems into a series of smaller independent tasks is one of the most valuable skills in project management. This is true in many fields, but thanks to the power of abstraction and modularity, it is especially powerful in software engineering, where small components can be built in separate settings and tested piecemeal as they are integrated into a larger whole.
This past week I found myself pointing out the value of breaking down tasks upfront to several of my coworkers, so I put together a short list of pros and cons. On one hand, organizing big projects with many moving pieces as a sequence of intermediate dependent tasks…
- Keeps you focused, reducing the number of things you need to juggle at once. There’s no point in keeping a task top of mind today if you know you can’t work on it until another piece is done. This is related to the basic concepts of lean manufacturing and kanban, which most software engineers are familiar as precursors to agile.
- Defines a clear path to the goal. It’s much easier to understand the project as a whole by understanding sub-tasks. This is related to the psychology concept called chunking.
- Provides better effort estimates. Hofstadter’s law will always be there, but it is easier to identify how much time is required to do each small task, reducing the overall variance of your estimates.
- Gives you an intrinsic sense of accomplishment as the project progresses. A single big ominous ticket hangs over your head, not done, but it is easier to stay motivated when you can check items off the to-do list as you go along.
- Allows you to show incremental progress externally. At your next stakeholder meeting, when the other team’s manager asks if the project is finished you can point to the list of subtasks, and instead of saying it’s not done you can say you are 7/10 of the way there.
- Enables collaboration. If you’ve done the legwork to chunk tasks into self-contained pieces it’s easier to hand off bits to peers who have a spare cycle or two.
On the other:
- It takes time and effort. Every minute spent organizing a project into smaller pieces is time spent PMing, not building your product. The smaller the project, and the smaller the team working on it, the less need there is for in-depth project management. Importantly, time spent on this kind of work feels productive and can easily turn into bikeshedding, so you should err on the side of cutting the task breakdown process short.
- It gives us a false sense of certainty. The task list should act as a guide. You don’t know what you don’t know, and there might be hidden work that you won’t see until you hit a roadblock. Some tasks you initially thought would be necessary might become irrelevant later on, and others that you thought were separate are actually tightly coupled. The team must stay flexible, changing tasks from your initial set, expecting them to evolve as the project unfolds.
Identifying self-contained chunks is really hard, but it is a worthwhile skill to hone. It often boils down to gut feeling and pattern matching, so I am not advocating for a specific way of going about the process of breaking down tasks, but instead arguing for the value of front-loading it. Tasks are fuzzy, and often bleed into each other. Whether you dedicate time upfront to organize your project into small tasks, or instead implicitly define tasks on the fly as you chip away at the larger whole, every project requires chunking. Considering you have to do it anyway, why not front load it and get the additional benefits listed above?
Photo: Catan Board, Bad Aussee, Austria, by me. Previously posted on Europa III, Bad Aussee MMXX.
Want to see more articles like this? Sign up below: