|
May 30: Portland OR:
RailsConf 2008 |
|
Wanted: Agile Java Development - Senior Software Engineer
at Tacit Knowledge (San Francisco, CA 94111).
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. Discuss at joel.reddit.com
Students: Fog Creek Software has awesome summer internships in New York City. You get free housing, free lunches, lots of free New York activities, and a chance to write great code with great developers. And a competitive salary. Apply today: we only have four open positions and usually get hundreds of applications, which will be considered on a first-come, first-served basis. 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 has been translated by volunteers around the world into more than thirty languages.
Want to hire great developers? Looking for a job that doesn't suck? Check out the popular job board or the job board for India.
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 make FogBugz, a bug tracking system that actually works and can be used to manage everything your development does, from bug tracking to customer email to feature management to project scheduling and so much more. Check out the screenshots or the free online trial.
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 three-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.
So far, this site has been made into three books: User Interface Design for Programmers, Joel on Software, and Smart and Gets Things Done. All are excellent ways to catch up on years of the drivel that appears here without going blind reading it on a tiny screen. I’m also the editor of The Best Software Writing, a collection of other people's superb essays about software. 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 | ||