Joel on Software
Oct 27: Boston:
SD Best Practices
Search:

Wanted: Software Engineer at Alelo (Los Angeles, CA 90066). See this and other great job listings at jobs.joelonsoftware.com.

From the "you call this agile?" department


This item ran on the Joel on Software homepage on Wednesday, November 15, 2006

Dmitri Zimine has a hypothetical story of how interrupting a programmer for a two hour emergency request needed to close some sale can actually waste two weeks. "If Sarah spends just two hours thinking of her old project, she loses a day of productive work on the new one," he says.

I agree that context switching is harmful. Absolutely.

Dmitri points out that the development manager should "tell the developer to stick to the original plan. Offer to protect her from switching her mind context. Remind her how cool it is to work single-mindedly on an important and interesting project. Ensure her that I'll handle the pressure."

This sounds like something I would agree with, too. I completely agree that management has a responsibility to provide an abstraction layer for programmers, so programmers can pretend that the outside world doesn't exist while they work on code.

However, something in the conclusion here strikes me as odd. Dmitri is only looking at one side of the cost/benefit equation. He's laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn't even mentioned arguments for the other side: the important sale that will be lost.

Agile development is supposed to be about agility. It's supposed to mean that you can change plans quickly. It's not supposed to be about rigid programming teams who are so slavishly devoted to their Two Week Plans that they can't rearrange their schedule a bit to serve the needs of the customer. Dmitri's conclusion, I'm afraid, strikes me as the very opposite of agile development. Agile is not supposed to be about swapping out one set of bureaucratic, rigid procedures for another equally rigid set of procedures that still doesn't take customer's needs into account.

I don't know the details of this hypothetical example. Maybe in real life the customer's needs weren't really that urgent. But maybe they were? Maybe this customer would have saved the company and made everyone a web 3.0 millionaire, but Sarah's doctrinaire insistence on following the Two Week Plan (because it was "agile") made them lose interest? Not sure... there's only one side of the story here.

Recently Microsoft released a new version of Internet Explorer. They introduced a bug in proxy detection code which caused a very small number of Copilot customers to experience crashes. Meanwhile, the Copilot development team, informally known inside Fog Creek as "Ben," was busy trying to get Copilot 2.0 out the door. But you know what? Our customers who had installed IE 7 were experiencing crashes. This was not acceptable. Ben stopped what he was doing, installed the old version of the compiler, checked out the old source code, fixed the crash, and pushed a patch out to the server. It interrupted and delayed Copilot 2.0, and the context switching was harmful. But it was still the right decision to make. Being able to do mentally difficult things like context switching makes our product better. This Is Why Programmers Get The Big Bucks. The whole reason you gave them Aeron chairs, unlimited M&Ms, free catered lunches, and the kickass computers with the 30" LCDs is so they can deal with new bugs Microsoft introduced in their code by messing up a DLL that used to work.

Yes, context switching is painful. Yes, you need to take into account the costs of context switching when you interrupt someone's work. But every decision has pros and cons and when I hear a manager who is just talking about the cons without considering the pros, that manager is not doing their job.



My new book is here! Apress has just published a new collection of 36 essays from Joel on Software, aptly named More Joel on Software. Get yours today! Available from Amazon.com or wherever fine cheese is sold.

About the Author: I’m your host, Joel Spolsky, a software developer in New York City. Since 2000, I've been writing about software development, management, business, and the Internet on this site. For my day job, I run Fog Creek Software, makers of FogBugz—the smart bug tracking software with the stupid name, and Fog Creek Copilot—the easiest way to provide remote tech support over the Internet, with nothing to install or configure.

Enter your email address to receive a (very occasional) email whenever I write a major new article. You can unsubscribe at any time, of course.

Email:

 
Home | Email | Bug Tracking Software | Remote Assistance | Complete Archive