Even simple multi-tasking can make a project 30% late

4 Comments

• Ammar

  August 9, 2007
  11:52 am

  Similar thoughts are shared by joel spolsky on his blog. Here are some extracts

  “The trick here is that when you manage programmers, specifically, task switches take a really, 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 zillions 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. If you send that programmer to Crete for a three week vacation, they will forget it all. The human brain seems to move it out of short-term RAM and swaps it out onto a backup tape where it takes forever to retrieve.”

  you can read the full article here
  http://www.joelonsoftware.com/articles/fog0000000022.html
• Jehan

  August 9, 2007
  1:17 pm

  Ammar, I totally concur with Joel that multi-tasking for programmers is a complete no-no. I have noticed that when they are programming full-throttle, even a phone call can put a halt to the process. And it irritates the hell out of them. The question is, is this equally applicable to other members of the team – i.e. interface designers, project managers, operations managers, etc.?
• Osama A.

  August 9, 2007
  6:23 pm

  I dont think Managers shoudl be affected by thread switching — in fact all good managers should be ABLE to switch threads and gain the new context in the shortest amount of time — how else will they manage a myriad of issues from their team and environment?

  Interface design — however — isnt just a creative art. It also requires keeping in mind a large number of target workflows, user demographics, use-cases, other related interfaces and more. Ofcourse that depends on how well defined and consistent the “global interface” rules are (e.g. all File Open dialogs should look the same etc).

  From my side I love task switching — its a sure-shot way of keeping at a 100% of personal productivity. That’s the only way I have been managing Green & White, consulting, running a company, designing products, planning new initiatives, not to mention the administrative / operational stuff.

  However I absolutely agree with programming — there is just no way to multi-task and program, and any time I have to look at anything I’m faced with a 2-3 day rampup time (to put everything in short-term RAM so to speak) and then a 100% mental capacity and bandwidth spent on the code itself.

  Personally, I consider this a weakness of IDE user experiences, not necessarily a consequence of the work.
• Osama A.

  August 9, 2007
  6:34 pm

  Some additional food for thought tho, and this comes from traditional supply-chain management:

  Task switching becomes painful when the load-time and tear-down time are too much and the actual processing does not maintain state.

  Consider an assembly line where you can either make Widget X or Widget Y but not both. The production-time (goign from one point to the other in the assembly line) is 30 mins, but rampup and teardown time each is 2 hours. Its stateless because you cant just “pause” the open parts when you want to make widget B — you just have to take everything off the table and start again.

  The human mind in some ways is similar — there is pretty much ONE main assembly line. Some of the smartest people are able to create two but then that’s not everyone.

  The rampup time is the time used to gain context. The teardown time is the time taken to write everything down somewhere so you dont forget later on.

  Phonecalls disrupt this assembly line — its like one of the machine breaking causing the entire line to stop, or worse.

  So how do you solve this problem?

  1- You use some way of scheduling the items loaded in the assembly line by order of priority, opportunity cost, and total production expectation of the day.

  2- You find a way to minimize rampup time — usually (in SCM) by preparing “ready to go” kits of the parts, along with “fixed rules” of how those parts will be processed.

  3- You add a way of maintaining state — as an example, what if you could simply move the actual table with all the parts just like they are, put in a blank table, make Widget B, then move tableA back in?

  In the above three things, “fixed rules” are the processes established in the firm, “parts” are pieces of information or context needed to complete your task.

  I think the above three duties is what software productivity tools should be doing — unfortunately most only focus on #1, and not context maintenance.