DEV Community

Cover image for Your Tasks Are Too Small (And It’s Slowing You Down) - Perform tasks in parallel
EmberNoGlow
EmberNoGlow

Posted on

Your Tasks Are Too Small (And It’s Slowing You Down) - Perform tasks in parallel

We've all heard advice like "break big tasks into smaller ones" and "don't try to tackle everything at once." But does this really work? Or can small tasks actually limit us?

Teams spend 30% of their time planning subtasks that later turn out to be redundant. Here’s why.

Why decomposition is popular

By breaking a large task into smaller ones, we get a lot of "cool features":

  • Reduced cognitive load.
  • More accurate estimation.
  • Visibility of progress (many small checklists are closed).
  • Ease of work distribution.

But this can negatively impact your productivity. And no, this problem is not just one point. All of the above benefits can turn your project into a living hell.

Problem

If you work in a SMALL team, or even alone, task splitting is your main enemy, and here's why:

small tasks encourage not the achievement of a goal, but the checking off of a checklist.

Let's imagine a situation. You're creating a code editor (for example, something like Notepad++ or a mini version of Code). Your large task consists of several items (this is what a "code editor" actually is):

  1. Text field, syntax highlighting and checking
  2. Terminal, output, console.
  3. Interface. Ranking the importance of these three items would seem easy – first, let's create a text field, then a console, then an interface.

Okay, you've gotten to work, starting with item 1.
We'll break this item's task down into smaller ones, and end up with something like this:

  • Create a window
  • Create an interface
  • Create a text input element
  • Create syntax highlighting

Okay. Let's complete the tasks in order and move on to the next item: console, terminal, output. Let's break it down into smaller steps:

  • Create an interface element
  • Create a function that launches a console process
  • Create a command input

As you can see, this task turned out to be easier than the previous one. But did you see that creating an interface and input is common to both tasks?

That's the problem with decomposing large tasks—you don't realize that the broken tasks might overlap, and you'll have to do another step that you could have combined into one.

This brings us to the next point:

It takes a lot of time!

While you're planning stages, breaking tasks down into smaller ones, checking for overlapping task types, and even taking notes and estimating them, this wastes 80% of your time. This is even more pronounced if you're doing this not in a simple notepad but in a specialized app, you quickly get sucked into the game and don't notice how time flies.

At least you have a clear plan, which will benefit your team, but mostly, it's a waste of time.

Tasks that are too small may be assessed

If you've created a detailed estimating plan, you might have added a task that's so small it doesn't deserve attention. For example, the task "Change the color of the button" isn't worth estimating. It's worth 5 minutes. If estimating takes 5 minutes, you're in the red.

Moral component

It would seem the most obvious. The bigger the task, the harder it is to pull yourself together. However, the more small tasks you have, the more daunting it is to tackle them, due to the sheer volume of work involved.

So what should we do then?

The answer is simple: divide large tasks into several chapters, and work on these chapters in parallel. For example:

We want to create a code editor. We've already defined what it is:

  1. Text input
  2. Debugging tools
  3. Interface

Now let's work on all three of these chapters in parallel:
Create a program window -> create a text field -> create a terminal field.
And we immediately see the finished result. Of course, this isn't a finished application yet, but it's more than just checking off a checklist.
We can further improve the functionality using the same principle.

Why is this method better?

We're essentially dividing the task not into a million subtasks, but into several larger parts. By completing these tasks in a staggered, parallel fashion, it's easier to "kill two birds with one stone." While this creates "creative chaos," it also saves you from the main problem: getting stuck on one task and not being able to start others until you've completed it. Thanks to chaos, you can always return to it later, even in a few days or even weeks. After all, the world is chaos, and perfect planning disrupts it.

Top comments (0)