Programmer Musings

Another View of Human Multitasking

I've recently finished reading Joel Spolsky's Joel on Software in book form. In the book, I read the essay Human Task Switches Considered Harmful. As someone who has had a lot of experience with multitasking myself, and a fair amount with computer multitasking, I found this claim to be pretty amazing.

I have looked at Joel's claims pretty carefully and believe I see the difference between my experience and his. I suggest you read his arguments before continuing so that I don't accidentally misrepresent what he is saying.

The general gist of Joel's argument is that there are two major problems with multitasking:

• every time you do a task switch, there is overhead


• since neither task finishes early, the average time for completion is higher

These points are both true for computers as well. If we follow his logic for computers, we see that we should never use multitasking on a computer system either. Since we do. there must be some point where the logic breaks down. To my eyes, Joel's argument is a little simpler than the reality I live in. First of all, there are two major times when a system needs to task switch: after a defined time-slice and when blocking on a resource. Joel's analysis is based solely on pre-emptive time-slicing.

Any time a processing system performs a task switch because it ran to the end of its time-slice, we incur the cost of the task-switch overhead. On the other hand, if the task switch comes because we are blocking on a resource, the cost of the task switch is not as important because the current task cannot continue. Another task gets a chance to run sooner than it would have, so the overall time is reduced.

The main purpose for pre-emptive multitasking is to prevent one task from absorbing all available resources (cpu-time) and preventing other critical tasks from completing. This is obviously not the right model for a human, if completing tasks is highest priority. In this particular case, I agree with Joel completely.

This also explains why interruptions are so damaging to productivity. An interrupt forces a task-switch. You incur all of the overhead of changing state, just like in the time-slice case. In fact interrupts are worse for humans than for computers. If you know you will be changing tasks after lunch, you can generally aim for a good place to stop. With an interrupt, you have no choice of when it occurs.

On the other hand, I try to keep one major task and two or three minor tasks on my plate at all times. This way, when something causes me to block on the major task, (waiting on technical or business input, lack of some resource, a design problem that I just can't seem to beat right now) I can spend some time on the minor tasks. Every minor task I complete, is one more thing that actually gets finished. That way I don't spend the blocked time busy waiting (browsing the web, reading slashdot, etc.<grin/>)

Amusingly enough, one of Joel's counter-examples is the case where a project manager sets someone to work on three tasks because there is no way for the programmer to complete them all in the time allotted if he does them sequentially. This example is useful for two insights. The first is obvious, but people forget it in programming too. If you are processor-bound, more threads will not speed things up.

The second is more subtle. Even though it may not make sense from a technical viewpoint, it is sometimes more important to show progress than to complete more quickly. Most modern (general purpose) operating systems use pre-emptive multitasking. This is not to make things faster, which it generally will not do, but to make things more responsive. No matter how resource intensive the main task is, all other tasks get some time. Unfortunately, in business, sometimes it is more important to be moving forward than to complete.

It boils down to trade-offs, like everything else we do. If raw speed is what you need and there is no chance for blocking, Joel's suggestion of one task is definitely best. (Look at most embedded systems). If you have one major task, but there is some chance for blocking, adding a few low-priority tasks can help keep people busy. There is never a technically valid reason for a single person/processor to be scheduled for two or more critical tasks. Although there may be non-technical reasons (business reasons, responsiveness, etc.).

Unfortunately, many people latch on to multitasking just like programmers who are trying multi-threading for the first time. Without being aware of the trade-offs, you can easily make an incredibly slow system.

Review of Joel on Software

Joel on Software
Joel Spolsky
Apress, 2004

This book collects some of the best entries from the Joel on Software website. Joel has an interesting view of the software industry based on three years at Microsoft, time spent at Juno, and now with his own company. This is a guy with quite a bit of experience and some interesting insights.

The essays in this book cover a large portion of the fuzzy part of developing software. Joel doesn't spend much time on algorithms or methodologies. Instead, he focuses on the real process of developing software. If you don't believe programs need a functional specification, you need to read what Joel has to say. If you are not sure how to estimate projects, read on. If you would like to know how to hire great programmers (or would like to know why you should), Joel has some answers.

In reading these essays, I often found myself surprised by Joel's opinions. His explanations are clear, and his ideas are interesting. Although I do not always agree with his conclusions or interpretations, many times I feel he is right on target. Some authors make you feel that they are the authority on a subject. Joel sounds like a guy who has been in the trenches and has his own views of how things work. Even when I don't agree with him on a particular subject, the essay gives me another viewpoint to compare to my opinions.

Sometimes he seems to be thumbing his nose at conventional wisdom just to stir up an argument. In some of his essays, Joel takes a position against rewriting bad code, for the not invented here syndrome, against incentive pay, and for bloatware. Each of these essays is bound to tick someone off. But, in each case, his arguments are lucid and force you to re-examine the question in a new light. In the end, you may still not agree with him, or he may have changed your mind. Either way, he will have made you think about the issue more than you probably have before.

I would recommend this book to anyone who has been in software development for a while. I think new programmers are less likely to really get what Joel is trying to say. If you need to manage programmers, you also need to read this book. For those who have been here a while, it's an interesting and entertaining read.

Review of Effective C++, Third Edition

Effective C++, Third Edition
Scott Meyers
Addison-Wesley, 2005

I was really excited when I found out that Scott Meyers was releasing a new edition of Effective C++. The first edition provided a major step on the path for many of us from writing code in C++ to actually programming in the language. What surprised me was the fact that this edition was a complete rewrite of the original. As Meyers puts it, the things that programmers needed to know fifteen years ago to be effective are not the same things we need to know now. Many of the items from the original are no longer new or different, they are the accepted ways to program in C++.

As always, Meyers provides practical advice and sound explanations of his reasoning. Meyers also has an extremely readable writing style that does not get boring after the first chapter. In the first edition, some of the advice went against standard practice of the day, but Meyers did such a good job of explaining his rationale that you had to consider his position. In the latest edition, I found less of his advice to be surprising, but every bit as important. Even though many others have explored some of this territory, I see lots of examples of programmers who violate many of these rules and later regret them. Like the earlier editions, Effective C++, third edition serves as a great description of best practices for C++. Furthermore, if you haven't seen these best practices before, or you were not convinced by seeing some of this elsewhere, Meyers will make a good attempt to convince you.

As with the earlier editions, each item covers a specific aspect of programming in C++ that you must be aware of in order to make effective use of the language. Although it would be possible to gain some of this information by carefully reading the standard reference works, it would be hard to beat the clarity and focus of this book.

One of my favorite items in the book is number 1 where Meyers describes the richness of C++ and some of the pain that comes from dealing with the different facets of this complex language. He suggests treating C++ more as a set of related languages than as a single entity. In the process, he manages to reduce some of the syntactic and semantic confusion by showing consistency within each sublanguage. I am not doing his description justice, you need to read Meyers' version to be properly enlightened.

Meyers does not just focus on usage of the C++ language, he also touches upon important idioms applying to the standard library. He also spends some time on classes expected to join the standard library in the near future, like the Technical Report 1 (TR1) extensions. He also suggests checking out the classes available on Boost.org as a way to see where the language is going.

Another point that impressed me about this book is the level of professionalism in the editing. Lately it seems that spelling and grammar errors have become the norm in technical books. Personally, I find these kinds of errors distracting. I found one typo in the entire book and only a couple of spots where I needed to reread the text to understand what Meyers meant. In today's environment of hundreds of computer books coming out in a year, it is particularly nice to see this kind of attention to detail.

If you program in C++, you need to read this book. Unlike you might have expected, it is not a simple rehash of the earlier editions. Instead it is more of a completely new book in the series. Novice programmers can learn the correct ways to use the language. Experienced programmers can gain better arguments for best practices they are trying to establish and insights into practices they may not be as familiar with.

I can't possibly recommend this book too highly.