Multi-tasking the project plan

I had one of those weird moments recently where I made an analogy between two things that I have never before analogized. Namely, multi-tasking operating systems and project planning. I will get back to that in a moment but first, I have a possible reason why weird analogies are popping in my head that I would like to spend a minute on.

The reason is Douglas Hofstadter. I have been a fan of Mr. Hofstadter's writings ever since I read Godel Escher Bach in college. It was required reading in the geek circles I moved in, in those days and it had quite an impact on me. I also greatly enjoyed Metamagical themas, Le Ton beau de Marot which is a rare kind of book. Deeply personal on one hand and totally fascinating to a typesetting and language geek like me on the other. I cannot think of any book to compare it too. I have no idea where I would put it on a book store shelf to properly classify it.

I have recently started to read I am a strange loop and it is dovetailing perfectly with other current reading material around the Buddhistic conceptualization of that tricky little word "I". The book is from 2007 and contains fascinating reflections to earlier writings and is just full of fantastic stuff. Highly recommended.

Anyway, analogies are a big part of Hofstadter's thinking around the mind and how thinking actually works. I think with analogies all the time. Many of them are nuts, but somehow even the crazy ones help me somehow. I don't know where this one lies on the crazy useful spectrum but here goes...

Modern computers do many things at the same time. It is called multi-tasking. Humans multi-task a lot too and some people are better at it than others. I read somewhere that women are better at it than men. I don't know if that is true or not. Some of the multi-tasking that goes in computing is behind the scenes and users of computer systems - be they end-users or developers - do not need to be conscious that it is going on.

For example, as I write this my machine is doing all sorts of multi-tasking behind the scenes while I just concentrate on words. The internet is chattering in the background, an army of non-maskable interrupt handlers keep grabbing CPU time to stop various buffers from over-flowing, and so on. However, if I choose to do so, I can fire up a plethora of chat windows, database reports, weather simulations and ftp downloads so that they all run at the same time and I (there is that word "I" again) multi-task between them with the help of the computer.

So now, let us try and create a task list and a gannt chart for what I am doing. I am doing N things all at the same time. Maybe 20% of my time on X, then 30% on Y and so on. I do that every day. It is not an isolated incident. IT teams all over the world do that every day. They operate like multi-tasking operating systems. I.e. I start my day on task X. I plan to just spend 1 hour on it because I have lots of other stuff to do. 30 minutes in to it I hit a blocker. I cannot proceed on task X because I am waiting on and e-mail or a trouble ticket or some such. I switch to task Y...and so it goes. We all carry around in our heads, our own multi-tasking scheduler and we decide what to "run" how long to spend running on each task, what priority to give each task, what task to jump to when the current task "blocks"...Gosh, my head runs Unix!

Ok. Lets imagine that that is true by analogy. Imagine now that you have been tasked with putting together a task list, with dependencies, priorities and workload for your operating system to work on next month. How would you do it?

I believe that most of us would would do that declaratively. That is, we would declare the tasks and dependencies the priorities, the workload and we would then let the multi-tasking algorithms in the operating system decide what gets worked on and when it gets worked on. We rely on the algorithms to be clever enough to re-schedule blocked tasks, dole out resources for maximum efficiency and so on. Most importantly, we get ourselves comfortable with the fact the order in which work is done is non-deterministic. The multi tasking algorithms change work schedules on the fly based on past and currently-happening events. We are comfortable that there is no real "ETA" we can have for any piece of work as a result of the non-determinism.

That all sounds reasonable to me but the disparity between what we deem sensible for computers to do when it comes to multi-tasking and what classical project planning says about task scheduling seems striking to me. How can I sensibly capture a picture of what I will be working on next week given that there are N tasks and M factors that will influence what tasks I actually work on and I won't know most of M until they actually happen?

This is often the reality inside software development projects in my experience. Perhaps more so in other activities because the developers have got great tools to implement multi-tasking. They are called operating systems! They can work on N things at the same time because the machines provide a lot of help in remembering the state of each individual task (for large values of N).

How would Henry advise us to do our planning and draw pictures of the state of play? I cannot picture it. I can see the multi-tasking algorithm but I have no idea how to create a useful picture it : either of what is happening now or what is planned to happen in the future.

Do you?

ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon