Context Switches

Joel Spolsky responded to Dmitri Zimine's article about context swtiching. Dmitri talks about the developer pains caused by context switches and how abusing context switching can lead to lower productivity and less code for your dollar. Joel's response is that if you work against context switching, you are not being agile. He backs his reasoning with an example: a huge bug was discovered that crashed the browser for a loyal customer, so their 2.0 release was held back to fix this.

First of all, Joel declares that having two week release cycles is not agile, which I think is a faulty assumption to start with. Telling a client that they will have to wait two weeks for the feature of their dreams is not always the deal breaker situation Joel makes it out to be, in fact I would think most clients would be impressed if a company released a requested feature within two weeks.

More importantly, there is a huge difference between necessary and unnecessary context switches. The high priority bug fix that Joel mentions is indeed a good reason to switch contexts, however that doesn't mean that if some random person in Zimbabwe says that he wants them to add feature X before the next release, I would hardly think that would be a good reason to switch contexts and focus on X. There certainly should be some abstraction and safety nets in place to make sure that programmers switch context as little as possible but no less. To say, as Joel does, that a 30" monitor means that a great programmer should magically be able to switch context on demand for any reason is a gross over-generalization.

Abuse your car's clutch and it will eventually break, no matter how good of a car or how well you take care of the rest of it.