I got 99 problems, but that's better than one

I got 99 problems, but that's better than one

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…

On the other:

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: