Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Fact is, a team with five people working on five independent tasks may be able to proceed at high throughput, because of the cost of coordination when you assign multiple engineers to the same task.

That is, if you have chef A making a burger, and chef B making a salad, and chef C making a cake, then they can all go at full speed because they're using different parts of the kitchen and don't need to coordinate with each other much. Individuals pay for context switches, but teams can assign different tasks to different team members.

Or maybe I don't understand the point the article is trying to make here. It seems really obfuscated with metaphors involving burgers.



The problem becomes a lot more difficult and interesting once you start involving multiple people.

Should everybody have many or exactly one task assigned? Should one person be on stand-by for operations? Should tasks be paired to two developers? Whole team mob programming one task? Are all the tasks truly independent?

Should juniors in team have same WIP as seniors or is the limit counted for the team as a whole? I see some teams almost give juniors a backlog of their own with the most basic cookie cutter tasks, even if they are low in prio, just to get them on board. Other teams handcuff them together with a mentor doing normal tasks. Vice versa for tech leads who often have another set of tasks only they do.

If everybody is working on a task, then who will code review others work? This can end up in a priority inversion situation, if Alice finished working a high prio task, should Bob working on a low prio task drop his work to review Alice work or should he finish his existing work to keep within his WIP limit.


i think we're talking about giving a single engineer multiple tasks.


The article is definitely talking about teams. It says "teams" lots of times.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: