Perils of Multitasking!

For all the posts that have made an entry to my blog, I have been dwelling for a high percentage of time in the past! For all that I have cursed about my studies in school, PU and in engineering, which for most part of the time made me feel like a cow on ice, I am today a manager, albeit a technical one, shepherding a herd of cats called programmers! I felt I need to pen down what I consider as the most difficult job for a manager… managing people!! But wait, isn’t it what I am supposed to do as per my designation? Man management isn’t an easy job! When you're managing a team of programmers, one of the first things you have to learn to get right is task allocation. Two words that make you load one program into the startup menu, the MPP!! 

In an old world office, it would be as simple as sorting out files,(the paper cardboard ones, with lots of papers in them), and “file dumping” them in the peoples’ lap!! Poor souls with their single minded devotion towards “closing” the file, would work at their pace, file after file in a sequential manner. 

Cometh the age of computers and software, the buzz words such as “parallel”, “simultaneous” seem to be omnipresent in a manager’s vocabulary and they unleash it on the poor programmers in a status meeting in its full ferocity ! The result; unhappy subordinates venting it out on their keyboards and near coffee machines in the office or in the canteen with other colleagues! Although me being in the same manager league, beg to differ completely about working on two things at a time!! And since I am technical manager, my analogy would invariably take an example of programming! 

Hypothetically let me assume there are two CPUs, one which performs tasks in a sequential manner, and the other (more likened by the manager!!!) performs tasks in parallel!! Each CPU is required to perform two separate computations A and B, each consuming 10 seconds of CPU time. Our CPU that performs tasks sequentially would perform the tasks this way.

Computation A										Computation B
1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20

Another CPU that is multi-tasking would perform both the tasks simultaneously however its execution would be as follows:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

Hmmm, so what’s the fuss all about?? Most people's gut reaction is that multitasking is better. In both cases, you have to wait 20 seconds to get both of your answers. But think about how long it takes to get the results to each computation. 

In both cases, the results of Computation B (shown in orange) take 20 seconds to arrive. But look at Computation A. With multitasking, its results take 19 seconds to arrive... yet with sequential processing one of them is ready in only 10 seconds :) Yay Yay!!! Even if you consider the average computation times, a sequential execution would take on an average (10+10)/2, 10 seconds, whereas parallel execution takes (19+20)/2 which is 19.5 seconds. I am not even considering the amount of time taken for task switching and already we have a difference of 9.5 seconds on an average computation!! Before you readers stop reading further and click the tiny Red Cross mark on the right hand corner of your screen, I will stop my technical analysis here. However, computers are built modeling themselves on humans and parallel processing of work even in humans in pretty difficult, well, next to impossible actually!! 

OK, back to the more interesting topic of managing humans, not CPUs. The trick here is that when you manage programmers specifically, task switches take a really, really long time. That's because programming 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 programming. A programmer coding at full throttle is keeping lot of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. Bump into him to update him about your Facebook update, Disturb the programmer for a clarification, just poke him to send a neat little document about his work, or just in between out of nowhere, pop up a very small task of changing the variable names in another person’s code; his memory is down like a pack of cards…The human brain seems to move it out of short-term RAM and swaps it out onto a backup drive where it takes forever to retrieve. It really takes time to gather back thoughts, logic all over again and align back to that “zone”. Three or four such task switches or interruptions a day, are enough to ruin his day, and the quality of the software he is writing. The overall productivity and other dependencies down the chain like schedule take a hit. At the end of the day, it is you as a manager, who would be frantically playing number games in the MPP, to accommodate the schedule.

From my personal experience I have noticed that whenever one job is assigned to one person, they'll do a great job, but if you assign two jobs to that person, they won't really get anything done. They'll either do one job well and neglect the other, or they'll do both jobs so slowly you feel traffic on a Monday morning in busy Bangalore road in moving faster. That's because programming tasks take so long to task switch. As it turns out, if you give somebody two things to work on, you should be grateful if they starve one task and only work on one, because they're going to get more stuff done and finish the task sooner. In fact, the real lesson from all this is that you should never let people work on more than one thing at a time. Good managers see their obligation as removing obstacles so that people can focus on one thing and really get it done. When emergencies come up, they think about whether they can handle it by themselves before delegating it to a programmer who is deeply inundated in a project.

Things are easier said than done!! Being a manager myself, I strive really hard to ensure that one person is working on one and only one thing at a time but it is real hard work!! The end objective achieved, when I have a happy subordinate who is always willing to work for me, and also have super-efficient robust software running in our product. Win-Win situation all round!!!A dream day when I just keep browsing, updating my blog whole day, drinking tea!!! occasionally poking my team mates asking "Whats the status?" :)

A[V]I