The Dev World – Sergio Lema

The tasks don’t come one after the other. A new task doesn’t arrive when you finish the last one. And when they came all together, the priority is never so clear.

When I was working on a hotel search system, we had a simple process to prioritize every task on the complexity and urgency.

This way, we could dispatch the tasks and solve them in the best order.

Let’s see how to effectively decide the priority of each task depending on the complexity and the urgency.

Not Complex and Not Urgent

The easiest one. Those are the tasks that can be delayed to do later.

Tasks like changing the header size, or adding a new column in the database.

We can delegate them to newcomers or Juniors. As they are not urgent, the developer can take time to understand the project, the context and the procedures.

Complex But Not Urgent

Then come more complex tasks or bugs, like the price calculation process or promotions.

As they are not urgent, those tasks must be estimated and divided into subtasks. This way, I can delegate each subtask, test each subtask and follow easily the development of the whole feature.

For those tasks, we needed meetings to understand the impact and define clearly the scope.

The main point here is to spend enough time at the beginning to correctly divide the main task and explain each part.

If I divide and design each subtask efficiently, I can transform each subtask into a task of the previous category, not Complex and not Urgent.

Not Complex But Urgent

Now it’s time to rush. The production is impacted. We’re losing clients and money. The bug must be fixed as soon as possible.

Those are mostly bugs, or changes on third-party systems that we didn’t expect.

After a quick investigation, we can figure out if it’s complex or not.

If it’s simple, and everybody is aware of the problem and solution, anybody can do the job.

The urgency should not be a problem. Junior or Senior, anybody should be able to solve the problem. I don’t need to book the senior’s time to solve this kind of issue.

Complex and Urgent

This is the most critical case.

The production may be impacted. The solution isn’t easy. Time is crucial.

The bugs I’ve seen in this category are those which are only visible with some load or concurrency. When testing on the staging environment, we can’t test with a high load or concurrent users. But this goes on production and the higher load causes a problem, it’s always blocking.

In those cases, the first thing to do is check the impact of the problem. All the team, or at least the most seniors, should be consulted.

What solutions do we have to mitigate the problem? How can we add a quick fix? Do we lose data?

From there, if a quick fix can be integrated as fast as possible, it’s the best option. Otherwise, a partial rollback can also fix the problem. This gave us more time to find a stable solution.

Then, we have more time to find a proper solution. This, way we can handle this situation as Complex but not Urgent.

Conclusion

The point is that for the user, everything is urgent. And for Junior developers, everything seems complex.

It’s the task of the Senior developers to understand and categorize each task and bug. Then dispatch it to the team.