Focus: Assign multiple engineers to the same task

Have you ever noticed that Jira (and most if not all) SWE work tracking systems allow assigning only one person to a given task? The whole industry (at least where I've seen it) runs around the assumption that at the bottom “one task == one person”.

The more I think about it through the years, the more confident I am that it's a very unproductive thing to do, and we should default to two people working at the same time on a given task. In complex domains, sometimes potentially even three.

Probably at some point you have experienced how quickly things can get done, especially in case of emergencies (like “OMG, something is wrong in production”) where multiple people with different skills and knowledge jump together into one “room”?

I've recently read The Goal, which I highly recommend to everyone. My favorite aspect of it was how down-to-earth it was in how it illustrates the performance issues of complex systems (especially made of humans). Surprisingly a lot of its findings are very relevant to both:

• How one optimizes any non-trivial software application.
• How human organization performance can and should be optimized.

I highly recommend just reading it, but in a nutshell: it's harmful to optimize the performance of every single unit individually, without regard for the effect on the organization as a whole which is what actually matters.

Most software companies I've had an opportunity to observe fall into that trap: they think they want to get done as much as possible, so they assign as much as they can to as many people as they have, thinking this optimizes the overall throughput. Oftentimes it's as bad as absolutely always (“each sprint”) assigning more work than possibly can actually get done given historical evidence, and sometimes it's more benign “each person works on one ticket, but each on a different one so we can make progress with as many things as we can”.

From the perspective of a single task, what tends to happen is: the person assigned to the task does not know everything about how to accomplish it well. In SWE no one can be an expert in everything. One person knows the architecture of the system better, another has no experience with the performance of database queries, another is an expert in the programming language being used, and so on. Oftentimes they will either have to slow down and learn this and that, by reading some stuff online and internally asking questions. That is a slowdown and it often generates a lot of interruptions and delays for everyone. All other people are busy with their work, so getting answers is often slow. Sometimes meetings have to be scheduled for sync-ups and cross-coordination with other related tasks assigned to other people, and everyone is wasting a lot of time blocked with some relatively minor things on other people.

Eventually, there's some conclusion: typically a PR is to be reviewed. And then some other person – often just mildly familiar with the work being done has to make a huge context switch and review the new code. By definition, that person can't be as familiar with the task as the author of the change. And here is where things tend to go bad in a really visible way.

Either:

• The reviewer is very familiar with the problem and the author did a great job and everything goes smoothly. That's the only happy path.
• The reviewer is somewhat familiar with the problem and actually gives good feedback, unfortunately sending the author back to redo parts or the whole change.
• The reviewer is not very familiar but is not aware of it and there's a huge debate between well-intended but wrong reviewers, wasting everyone's time.
• The reviewer is not very familiar and just rubber-stamps, potentially suboptimal or plain bad approach, to get back to whatever task they have assigned at the moment.

The chance for the happy path is pretty slim here.

From the overall perspective of the organization how it looks like is that there's tons of work in progress, but hardly anything ever reaches a conclusion. Or at least: the tangible results are being delivered much more slowly than anticipated, which often results in the knee-jerk reaction of management to try to parallelize and take on more work at the same time, making things even worse.

Let's contrast with an approach where two (or even more) engineers with somewhat disjoin skills were assigned to one task:

They remain in tight sync, bouncing at each other ideas and being a real and responsive rubber-ducks. This effectively works as a pre-code-review, way before the work even starts. Their total knowledge and skills are a sum of the skills of each member. The chance that they come up with a wholistically good approach is much higher. They don't have to educate themselves on as many missing pieces because they cover more of them. They can use that opportunity to exchange knowledge and experience permanently enriching everyone involved. They generate fewer interruptions for the other members of the team. They need fewer meetings because they are continuously in sync. Even when the sync-up or other meeting is needed with other people/teams potentially only one of them can attend and the other one can e.g. keep coding or working on something tangible. By the time the work is concluded, the final code review is almost unnecessary, as everything, from the ideas, approach, implementation was potentially reviewed by two or more people multiple times already.

Note: pair-programming is somewhat like that, and is usually justified using the same arguments. However, I don't think the “coding at the IDE” part is the important one. The important part is that multiple people get deeply familiar with the problem, talk about solutions and approaches and take time and responsibility for addressing it. The coding part might or might not be pair-programming. It's entirely up to people working together at the solution. It might be better if one person does the implementation and pushes WIP commits for others to review and discuss. They can switch, they can split sub-tasks like research and asking questions around. They can parallelize a lot. The goal is only for all of them to be holistically engaged and in the context of what is being done.

Yes, overall fewer tasks will be worked on at the same time, but if you read The Goal, you will realize that this might actually be another benefit, and not an actual weakness.

And in the longer term the pairing (or as I like to call it: ganging) people on each task will lead to:

• faster technical growth of everyone due to exchanging knowledge and craftsmanship skills,
• better team cohesion as people work and interact more closely together against the same problem,
• better tribal knowledge dissipation,
• higher quality of the code and design,
• less burn-out as people can focus more on one thing with less distraction,
• the work actually assigned getting done faster as people working together can get it done much faster.

#altswe #swe #software

from Hacker News https://ift.tt/3A0qxTa