|
Oct 27: Boston:
SD Best Practices |
|
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?" departmentThis item ran on the Joel on Software homepage on Wednesday, November 15, 2006Dmitri 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. |
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. More about me.
There's a complete archive of everything going back to 2000. The home page is reserved for minor, ephemeral thoughts, but occasionally I write a longer article. You can sign up to receive email whenever this happens at the bottom of this page. We also have one of those RSS thingamajiggies. If you don't know what that is, consider yourself lucky.
This site is actively translated by volunteers around the world into more than thirty languages.
Want to hire great developers? Looking for a job that doesn't suck? Over 200,000 great programmers read my job board at jobs.joelonsoftware.com.
Have feedback? There are several popular discussion boards on this site: Joel on Software
Business of Software Design of Software .NET Questions TechInterview.org CityDesk FogBugz Fog Creek Copilot You can also email me directly, although my mailbox is an official disaster area.
For my day job, I'm the CEO of Fog Creek Software, a bootstrapped software company in New York, NY.
We also make Fog Creek Copilot, which lets you control someone else's computer (with their permission, of course) over the Internet. It's the best way to fix someone's computer problems remotely. There's nothing to install, it's simple as heck, and it works through any kind of firewall, NAT, or proxy situation with zero configuration. More
If you're in college, Fog Creek Software has a very cool paid internship program (last year's interns developed Copilot in one summer). We also run a Software Management Training Program, an intensive two year program for college graduates to learn about managing high tech that combines a Masters in Technology Management with extensive hands-on experience in a variety of positions.
Wondering what it's like to develop software at Fog Creek? The documentary Aardvark'd covers the story of the development of Copilot. It's available on DVD.
Fog Creek co-founder Michael Pryor has his own site on Technical Interview Questions.
© 1999-2008 Joel Spolsky. All Rights Reserved. Linking, quoting and reprinting
|
|
| Home | Email | Bug Tracking Software | Remote Assistance | Complete Archive | ||