Multi-tasking is a crime (at least in software projects!)
/Fact of life: More often than not a software team will have more work than they can juggle. What can a team lead do to get things done in the most efficient way?
Coming from a logical point of view she has the following algorithm:
Prioritize things and get the high priority things done first (of course! We have a no brainer here).
Given the prioritized list of task from #1 she can get her team members to
a) do one feature at a time
or
b) ask them to multi-task as in work on several features at the same time, switching between them.
The real debate is:
Is multi-tasking better than single tasking?
Multi tasking has been hailed as great solution to modern life’s challenges. Books, articles and research papers have been written showing it’s benefits for efficiency and performance. A little googling will lead you to articles such as this one aimed a entrepreneurs: Why multitasking has become the need of the hour? As you go through these you realize that it may indeed be a good thing and may solve your every day challenge of get different features of a software made (because you need to show different stakeholders different parts) in parallel.
However, in the world of software development there is a strong indication that multi-tasking is harmful. Let me quickly define multi tasking in this context - it is the act of getting the same resource (or a group of resources say a small team) to work on one part of the software and then move to another part within short intervals (hours, days but maybe not weeks). The effect of this kind of multi tasking is context switching - getting the developer(s) to load up one set of code, logic and idea in her brain and then after a while asking her to forget that and load up a completely different set. There is absolutely no question about this, context switching is bad for a software team’s performance.
Source: The Multitasking myth
In the book Quality Software Management: Systems Thinking, Gerald Weinberg writes how context switching affects performance. He showed that just like computers, humans often incur overhead when context switching between multiple parts of code or between multiple projects. He came up with a rule of thumb to calculate the overhead and showed that you lose 20% of your time by just adding one extra new context due to the overhead. And By the time you add a third project, nearly half your time is wasted in task switching.
If you think about it its quite obvious. When you are managing a software team, task switches take a long time. That’s because coding is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at coder. A programmer coding at full speed has in her head a huge amount of random yet useful bits of information that range from variable names, database tables where the variable will go, APIs that she will need to call next, the names of functions the team wrote in the library, the URL of the git directory, a stackoverflow article she read that uses a trick to solve the problem, the list goes on and on. The moment that programmer moves to a different task or worse a different project everything is lost and a complete new set has to take over - incurring that wasted time in the scheme of things.
So multi tasking makes a software team slow rather than fast. Your deliveries come later than sooner. So just like we can say with absolute certainty that cubicles are bad in a software company, we can say without a shadow of doubt that multi tasking is a crime in a software project. Here’s a good Dilbert for today…
