Forgot your password?
typodupeerror

You Call This Agile? 168

Posted by Hemos
from the the-perils-of-development dept.
JoelonSoftware's most recent piece is about some of the fallacies in "Agile" software and some of the issues within it. We use Agile in some parts of the company, and have had success with that -- that said, there's always the peril that happens when development and other parts of the company have...miscommunication, which sounds like the problem described in Joel's piece.
This discussion has been archived. No new comments can be posted.

You Call This Agile?

Comments Filter:
  • by ab762 (138582) on Monday November 20, 2006 @02:29PM (#16918074) Homepage
    Anytime that the process concerns dominate making product, supporting product, doing business, making money, you're in the soup. Any process, methodology, tool, language, whatever can be used to make product. And any process, etc. can become an idolatrous religion. Except Linux, of course.
    • by khasim (1285) <brandioch.conner@gmail.com> on Monday November 20, 2006 @02:55PM (#16918514)
      I can write any program you want within any time limit you want provided ...

      a. I don't have to support it.

      b. It doesn't have to work.

      Yes, that's funny, but it is not a joke. Processes are supposed to be about functionality and maintenance. A one-off app for a critical issue today doesn't need a process (except how to delete it tomorrow so it doesn't become part of they real system).

      And that is where marketing and development differ. Marketing sees the opportunities in selling "support contracts" for code that was rushed out, filled with bugs and features that don't work.

      Development only sees problems that they're going to have to fix. And fix today. And fix in the quickest possible way because the customers are complaining about a critical issue. And so forth.

      So the various processes (and project managers) are supposed to translate/support both views. Get it out in time to make the sales, with a stated minimum level of functionality and no more than X bugs of various levels.

      But, as you noted, it is easy to follow the process as the religion instead of recognizing that it is just a means of getting product ready for shipment so it satisfies marketing, the developers and the customers.
      • by emurphy42 (631808)
        A sane marketing department would think "instead of using crap as a foot in the door for support contracts, let's use good stuff as a foot in the door for more good stuff". (Assuming your developers are competent; if not, then the only sane move is to leave.) Not only does this avoid giving customers unreasonable expectations about how cheap/quick things can be done, it also avoids customers who already have such expectations when they walk in the door, and cannot be convinced otherwise; those customers a
      • I can write any program you want within any time limit you want provided ...

        a. I don't have to support it.

        b. It doesn't have to work.

        I prefer to put it as follows:
        • Good
        • Fast
        • Cheap

        Pick Two.
        • by N Monkey (313423)

          I prefer to put it as follows:

                  * Good
                  * Fast
                  * Cheap

          Pick Two.

          I quite like Terry Pratchett's twist on this:

          "Do you want it fast or cheap or good, gentlemen? The way things have gone, I can only give you one out of three."
          (from "Going Postal").
      • A one-off app for a critical issue today

        This is the most common mistake people make. If you need to do it today, you will need to do it again in the future.

        The business owner who asked for the one-off will want changes. Or it will turn out to be a good idea that upper management wants to make part of the monthly, weekly, or daily reports.

        The "one-off" application is an excuse to kick something out the door without design, documentation, or maintainability concerns. I would hazard a guess that fully

  • by yagu (721525) * <yayagu.gmail@com> on Monday November 20, 2006 @02:33PM (#16918132) Journal

    I think one of the blessings and curses of methodologies, in this article's instance, "Agile" (ha!), is they are their own universe. So, unless there is something within the methodology that is self-contradictory methodologies don't have fallacies. Methodologies are theses, usually tepid ones at best.

    Methodologies are someone's or some group's or some company's idea of a way to successfully accomplish a task, project, etc. Fortunately for all who sell these (vapor)wares, methodologies never fail, they merely suffer from those who have improperly used them.

    Methodologies then become the convenient whipping boy for work not done satisfactorily. Sigh.

    Peel away the layers, eventually it all still boils down to knowing what you want to do, knowing how to do it, and doing it with a strong instinct for balancing things that matter and things that don't. Methodologies won't do that for you, good project managers will.

    (Some of the very best and most successful projects I worked on were with a friend who I consider to this day to be one of the best project managers I ever knew (and I knew many). He used no methodology, but had incredible instincts and a strong will. He knew how to handle time frames, important (and not-so-important) crises, difficult workers, and how to prioritize. It's a shame he didn't get better recognition - he might have had he "used a methodology". I found it ironic he was ostracized/admonished by the company, but he continued to be their go-to guy for the important work.

    Bottom line, "Agile" isn't. But "Agile" is just one of a long list of bit players for methodologies in IT.

    • by RingDev (879105) on Monday November 20, 2006 @02:45PM (#16918340) Homepage Journal
      No offence meant to your friend, there are many people who have a knack for project management, but... Methodologies are kind of like stories. There are only a handful of distinct stories to have ever existed, every other story in existence is merely a slight modification or attempt at recreation of one of those original stories. While your friend may not have researched and followed any specific methodology, he likely practiced one with out even knowing it.

      In defense of "Agile", it can be (agile). But it takes the right mindset from the developers, project manager, upper management and customers. Agile will not succeed in environments where anyone in that chain does not have the "Agile" mindset.

      -Rick
      • by ivan256 (17499)
        Agile will not succeed in environments where anyone in that chain does not have the "Agile" mindset.

        So the methodology can't cope with a few bad apples?

        Chances are that in any group of 10 or more people, one or more won't carry their weight. This will either be due to incompetence, malice, or most likely, unexpected external events that take the team member away from their work. Nevermind that you included the customers in the chain. Most projects don't get off the ground unless you start with the customer
        • Agile will not succeed in environments where anyone in that chain does not have the "Agile" mindset.

          So the methodology can't cope with a few bad apples?

          Yes! The main difference between agile methods like XP or SCRUM versus the deterministic methods like water fall or V-Model is: the deterministic methodologies are designed to have a broad mass of low performing developers/project managers, brought on track by a small group of experts. The only thing that is important: make the development of work pieces e
          • by ivan256 (17499)
            Anyway: lots of critics against agile methods come from people who don't want to be agile. No offense. But if agile sucks for you, then very likely because you are not fit enough.

            That's a big honken' load of bull.

            First of all, I never said Agile sucks for me. I wouldn't know. I've only viewed these environments from the outside. It has nothing to do with being 'fit' enough, it has to do with the fact that I like to balance my work with the rest of my life instead of burning out young like the know-it-alls t
            • First of all in a sentence like: if agile sucks for you, then very likely because you are not fit enough. The you in such a sentence refers to the reader not you as a particular person ;D

              Anyway: you have a missconceptin about the term agile. Agile is not:
              o its not, working more than 8 hours
              o it's not wasting your energy on an attempt to burnout
              o it's not making over hours, over shifts or having no life

              I don't know why that is your impression. Agile is just the opposite of deterministic. In a traditional
    • by hhr (909621)
      It sounds like your friend instictivly followed "The Seven Habits of Highly Effective People" a methodoligy that not only applies to software, but every damn thing goal you have.

      In one sentence "Seven Habits" is-- know what's important, know what's not, only work on the important. That's a big over simplification that doesn't do justice to the book.

      I recommend that every developer read "Seven Habits." Developers aren't the only people in the world who have to manage long and complicated projects. You'd do y
    • Re: (Score:3, Interesting)

      by drooling-dog (189103)
      Formal methodologies won't save you from poor management, but they do serve to get everyone associated with a project on "the same page". I'm often skeptical of the claims made for one methodology vs. the next, but they all look pretty good compared to nothing.
  • by smbarbour (893880) on Monday November 20, 2006 @02:36PM (#16918172)
    This article appears to be written by Captain Obvious and his sidekick, Common Sense.

    Yes, it is nice to have a dogmatic approach to programming, but ultimately it really boils down to "what course of action will have the greatest benefit to the company?" It has always been this way (even outside of software development) and it always will.
    • That's pretty much the jist of it. Nothing accounts for every possible situation, not even buzzword methodologies. Do what you think is best.
    • It's for the customer!
    • This article appears to be written by Captain Obvious and his sidekick, Common Sense.

      very true. but at the same time, people so frequently seek out dogma in order to justify their way of doing things, or even just to find a clear path that doesn't involve much decision-making, that it's important to articulate these things explicitly from time to time, along with the reasoning behind it. besides, it's joelonsoftware, so it's obviously right.
    • by bill_kress (99356)
      Close. The actual statement should read more like "what course of action will be generally perceived to have the greatest benefit to those making the decisions"

      Even if you refactor "those making the decisions" to the company, you can't get away from the fact that if you can alter perceptions of the decision makers, you completely alter the course and outcome of the project.
    • Re: (Score:3, Insightful)

      by plopez (54068)
      Was it Voltair that said "Common sense is not so common". Wed have learned precious little in software development over the past 30-40 years it seems. People look for silver bullets and latch on to a methodology, such as Agile Development and end up reinventing waterfalls.

      People still think adding people to a project will in and of itself accellerate a project. They are wrong. Yet we do it over and over again.

      My question is, if supporting version 1.0 of an application is business critcal and developing vers
      • by mpaque (655244)
        The way I have worked and like to work is to use experienced staff for new development and younger hires for maintenence work. This gives you 6 months to a year to train the new developer, adds depth to the organization and allows the senior staff to focus more on larger issues. After 6-12 months you shift the jr. developer to new design and implenetation, under direction of a senior developer. Eventually you have a new senior developer.

        What a very odd thing to do.

        In many workplaces, a pattern is used that
    • by mpaque (655244) on Monday November 20, 2006 @05:41PM (#16921252)
      This article appears to be written by Captain Obvious and his sidekick, Common Sense.

      But the thing of it is, you see, is that Project Management has trouble seeing the obvious, and needs a regular kick in the pants.

      I am regularly asked about how long some feature or other will take to implement, and generally give a response in terms of man-days or man-weeks. What's fun is to see how this is interpreted by a Project Manager.

      "This feature will take 5 man-days to implement."

      Manager: "So, it will be ready on (20, 1, 2, 3, 4, 5...) the twenty-fifth. I'll put that on the schedule."

      "No. I said 5 man-days. That's not the same as calendar days, and we're shut down the 24th and 25th."

      Manager: "Oh, right. So, next Tuesday, then."

      "No, I said man-days, which are not the same as calendar days. We don't have any one who can start on this at once, and everyone already has work to do."

      Manager: "Oh. Well, can you start on this tomorrow, then?"

      *SIGH* And these are the folks who are creating all the pretty PERT and GANTT charts for senior management.
      • by CrazyTalk (662055)
        Where I work, the response to "We'll be shut down the 24th and 25th" would be "Well, then we will have to work 12 hour days and weekends then, because the deadline cannot be changed"
    • Yes. I've noticed that those two guys often complain about the great programming methodology du jour. If only the methodology gurus would listen to them more often.
  • by RingDev (879105) on Monday November 20, 2006 @02:37PM (#16918210) Homepage Journal
    ...miscommunication, which sounds like the problem described in Joel's piece

    Miscommunication? He's talking about context switching, which is an all too common and necessary evil in small shop development.

    In any given week I can switch from architecture design to business systems analysts, back to VB6 coding for legacy app maintenance, up to .Net for the latest report release, then into testing mode preparing another test release. All the while trying to convince my supervisor of the need for structure, project management practices, and tools to make our life easier.

    All that context switching definitely has a negative effect on my productivity. My supervisor asked me to tag tickets with time estimates when I closed them out. No biggie, but the shortest I'll tag a ticket for is 30 minutes. Originally I had said 1 hour, but my supervisor vigorously disagreed with my estimate of context switching's effect on productivity.

    -Rick
    • Re: (Score:3, Insightful)

      by 2short (466733)
      "No biggie, but the shortest I'll tag a ticket for is 30 minutes. Originally I had said 1 hour, but my supervisor vigorously disagreed with my estimate of context switching's effect on productivity"

      When doing planning-phase time estimates, our mantra is "Everything takes a day".

      A whole pile of little things in the same part of the same project might get done in a day, but if you're going to bother getting enough about a particular context into your brain to do real work, you better have something to do wort
  • by FortKnox (169099) * on Monday November 20, 2006 @02:38PM (#16918212) Homepage Journal
    ... isn't the whole issue with interuptions. That can be handled differently depending on the work (if you are making life-saving heart monitor software, you had better fix a bug the moment it comes up... if you are making some tool that other developers use once a week, a bug isn't that big of a deal)
    The real advantage is illustrated in the age old swing cartoon [uoregon.edu]. By using scrumm and delivering sprint demos often to the user, they can see how their money is being spent, and can present requirement changes to the user faster, thus eliminating the need to make resounding changes right away... Agile development anticipates requirement changes, instead of ignoring it like past methodologies. Is it the best? Probably not... is it a step in the right direction? You bet your ass...
    • Re: (Score:3, Interesting)

      I think people lose the point of Agile. Small, modularized, testable deliverables. User story and test-cases up front (not always practical though). We sort of use Agile at my current job, but often we find that if we do not lock down the high-level requirements you will never see the end of the development. I think what is key is small, discrete end-to-end deliverables. The flux on an interation should be encapsulated to that particular feature and then closed with the end of the iteration regression.
    • Re: (Score:3, Informative)

      by Doctor Memory (6336)
      if you are making life-saving heart monitor software, you had better fix a bug the moment it comes up

      Dunno, I would think in that case you'd want a more heavy-weight process, with lots of QA and regression testing. I mean, it's not like there's a guy sitting in a doctor's office with a CAT-5 cable plugged into his chest, waiting for you to download PaceMaker 1.1-A...
    • You may gain productivity at the developer level, but Agile DESTROYS productivity at the DBA and system programmer levels.

      We are prototyping some agile development. So far, I have had to REDO a pair of tables 8 TIMES because they keep changing their mind on the definitions. And the project isn't done yet. And when I say redo, I mean drop and start from scratch.

      My time (I'm the one DA in the shop and the MVS DB2 DBA)costs the company more than the time of the developer who keeps changing their mind, and i
      • So far, I have had to REDO a pair of tables 8 TIMES because they keep changing their mind on the definitions.
        So, taking you literally, they changed their defiitions so often ... and you had to redo a PAIR ... a pair is *2*, yes? Two tables?

        So, I don't really get what is so hard and expensive in redoing 2 tables ... but if that is the case, then you should start getting agile and lift your fat ass and report that this is a problem.

        The first rule of agility is: there is no the developers and us the DBAs. Ther
  • by zoftie (195518) on Monday November 20, 2006 @02:38PM (#16918222) Homepage
    He has capacity to speak his mind, as he took intensive courses on writing and expression in university, but that doesn't detract that his ideas are his and to each idea there is the opposite side that has just as many positives, if presented correclty.

    Aglie development works, but only if people can be trained. Training is something that is omitted when it is decided on whatever model you want to adhere to. Remember we are all just animals and the more training we get, the better we are at it.

    Agile process is based on feedback, and therefore programmer must be trained to appreciate and nuruture feedback from his practices too. Programmers need candy too, for rewards, and that candy is a feedback from wroking code. Given, if you are writing a disk driver, feedback is limited, compared to game developer, writing graphics or sound enegines. What Agile brings, is that rewards come at a steady pace, therefore propping up motivation of developer from development side of things. Disk driver developer must find his way to recieve rewards from developing driver code, perhaps thats why compensation is higher for the driver developers, because work has no immediately accessible of stimuli and chances to get negative stimuli, like corrupt disk of the user, are quite high.

    If you code not for the sake of itself, I pitiy those people. But then they aren't on the slashdot.
    • by supersnail (106701) on Monday November 20, 2006 @02:54PM (#16918504)
      The whole point of the "stick to the plan" and "no interuptions" rules
      is to focus project leaders on stopping trivial interuptions of the
      " who knows how to load paper " and " could you check over my presentation"
      type which will happen 10 times a day if there was no rule.

      Worse the avergage program will load the paper or check the presentation
      thus reinforcing the "its ok to interupt these guys there only programmers"
      attitude.
      If you have a rule and a fancy methodoligy its easier for the project
      leader to field interuptions without appearing rude and unhelpful.

      I used to go to the secure telecoms room when I had serious stuff to do
      as hardley anyone had access, nearly always got a chill from the AC though.
  • by autophile (640621) on Monday November 20, 2006 @02:43PM (#16918282)
    From TFA:

    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...

    Leakage from an alternate universe far from our own?

    ...is so they can deal with new bugs Microsoft introduced in their code by messing up a DLL that used to work.

    Okay, it's a universe very close to our own.

    --Rob

    • Re: (Score:3, Interesting)

      by StarvingSE (875139)
      I get a chair that has the height-adjust lever broken off, I get to pay for M&M's out of the vending machine, lunch consists of a brown bag at my desk, my computer only has 256Mb's of RAM to run bloated IDE's on, and I have a 17 inch dell CRT.

      Where do you work, and where can I submit my resume?? ;)
      • Re: (Score:3, Informative)

        by MrNonchalant (767683)
        Joel owns Fog Creek Software and their jobs page is here [fogcreek.com]. Alternatively there's another small company [google.com] that has similar fantastical working conditions. Both, however, are reputedly hard to get into. If only more companies thought that way. Even free food/drinks is a big step in the right direction that doesn't cost a lot.
    • by xero314 (722674)

      From TFA: 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... Leakage from an alternate universe far from our own?

      If you knew Joel's history you would see that this is how things work in the universe, at least around him and his company. This is also why he has a successful company which produces high quality software (I'm not saying I like their products just that it is of a very h

  • not Agile (Score:5, Insightful)

    by yaphadam097 (670358) on Monday November 20, 2006 @02:59PM (#16918586)
    In the hypothetical scenario the customer introduces a critical story in the middle of an iteration. This can and does happen in Agile projects. The only problem is that the team may not be able to deliver something that it thought it would because it will be spending effort on the new story. That is ok. The primary goal of Agile is to give the customer the ability to prioritize work and manage the creation of business value.

    Also this aversion toward "context switching" isn't particularly Agile. The idea behind TDD, evolutionary design, and small time-boxed tasks is to work in small chunks. I would argue that the ability to "context switch" developers while still developing value incrementally is the whole point of the Agile approach.
  • by dsci (658278) on Monday November 20, 2006 @03:18PM (#16918928) Homepage
    Seems like this is just another shot in the feud between Spolsky [joelonsoftware.com] and Heinimer Hansson [loudthinking.com]?
  • "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." -- Try a 5 yrs old computer, an uncomfortable desk,a chair that must have been bought at some office furniture auction from the 80s, a monitor that makes me feel like I have the eyes of a 75 year old and a boss that says fun is
    • by bentcd (690786) <bcd@pvv.org> on Monday November 20, 2006 @06:16PM (#16921804) Homepage
      Spolsky comes from a world where management realises that in order to get effeciency out of programmers, you need to treat them right and give them the tools that they need for the job. Now, this may be common or it may be rare, but it most certainly is the right way to run a programming shop. So when he says "this is why programmers get . . ." what he really means is "this is why _my_ programmers get and this is why _everyone's_ programmers should be getting . . ."
      Of course, he's also a but picky about what he'll accept as a proper "programmer" :-)
    • More important than what planet he's from is "Is he hiring?"
      • by xero314 (722674)
        Yes he is hiring. He is always hiring. But got luck getting his attention. Joel's company hires what is truly the cream of the crop. No I have not been rejected by his company, but I know enough to know that I would have to put in more than a few months as an unpaid intern if I wanted to get my foot in that door.
  • by agilen (410830) on Monday November 20, 2006 @03:23PM (#16919032)
    I think the point missed by both articles (Joel's and the one he is commenting on) are that specific examples are bad. The real problem is making a habit of emergencies. When you fly by the seat of your pants and constantly have engineers fixing emergencies, then yes, it has a very negative impact on their productivity. Once in a while, however, is to be expected and is okay.

    Really what any organization should do is instill the resources and culture for proper QA and operational support for developers. If calling the original engineer is the _last_ resort, because QA didn't catch a bug and operations can't fix the problem, thats fine. All too many organizations, however, have an engineer getting called first for a problem that probably should have been caught by QA, or that should have been caught by the operations people. Engineers hunting down problems and finding a reproducible case constantly is really what kills productivity. If the culture is "don't worry, if its broken the engineer who made it can take time out of their current projects to fix it", then your organization is broken.
  • by SuperBanana (662181) on Monday November 20, 2006 @03:26PM (#16919072)

    Why do I see Joel constantly talking about how disturbing it is to "context switch", when sysadmins like myself are expected to handle a dozen or more tasks, most of them "surprise" stuff, daily? Don't tell me "oh, programming is complex"- so are networks.

    So, you get unlimited M&Ms, a 30" screen, aereon chair, and get all upset when you spend an unexpected 2 hours out of your 8 hour workday on an emergency, one a week or so. Meanwhile, I'm working on whatever was left in the IT supply room, have to carry a pager, work 10 hour days because I'm doing 2-3 people's jobs- and I've got a half dozen long term project goals...but I'm getting bugged HOURLY to fix the most trivial shit by programmers who can't be bothered to stick paper in a printer?

    If Sarah was a sysadmin and had to waste a day collecting her thoughts after spending two hours fixing a mysql database, she'd be fired. You programmers need to stop behaving like prima donnas.

    • Re: (Score:2, Funny)

      by androidqueen (1014367)
      well, of all the . . . i can't work like this! i'm the *talent*!

      if anybody needs me, OR WANTS TO APOLOGIZE, i'll be in my trailer.
    • Re: (Score:2, Funny)

      by Anonymous Coward

      Why do I see Joel constantly talking about how disturbing it is to "context switch", when sysadmins like myself are expected to handle a dozen or more tasks, most of them "surprise" stuff, daily? Don't tell me "oh, programming is complex"- so are networks.

      So, you get unlimited M&Ms, a 30" screen, aereon chair, and get all upset when you spend an unexpected 2 hours out of your 8 hour workday on an emergency, one a week or so. Meanwhile, I'm working on whatever was left in the IT supply room, have to c

    • Re: (Score:2, Insightful)

      by gdeciantis (570658)
      I actually work with Dmitri and his developer "Sarah". I can tell you that his team has pumped out more product than any other company that I have worked for and we don't have unlimited M&Ms or 30" LCDs, so I can relate to those comments. Also that comment about prima donnas. Pragmatic programmers take time before they start coding. Please, leave your anecdotal bullshit at the door. We are talking real life.
      • I see a logical disconnect:

        Please, leave your anecdotal bullshit at the door.

        can tell you that his team has pumped out more product than any other company that I have worked for and we don't have unlimited M&Ms or 30" LCDs, so I can relate to those comments.
    • Pardon the rant, I'm having a cynical week this week.

      Used to be, there were generalists writing code. It was possible for one person to understand security, IO performance, database design. Not any more. Now, projects, even individual applications, are too complex to be understood by one person. This forces specialization. Back in the day, system administrators were often the in house generalists, accepted as relatively unproductive coders, but peers in the architecture process.

      Nowadays system administrator
    • by Tim Browse (9263) on Monday November 20, 2006 @04:23PM (#16920012)

      So why not become a programmer? Apparently, you'd work less hours, have better conditions, a better defined job, and not get interrupted all the time.

      After all, I'm sure programmers' jobs are easy. Just make the switch.

      In the meantime, junior, pipe down and fix the mail server.

      • Pansies. I AM a programmer. I context switch about 20 times a day. I have *THREE* major projects going on right now. Guess how I handle it? Multiple Desktops! Yeah, 1 for each project. (And don't complain that you are in a Windows environ, you can have multiple desktops in Windows.) Context switching costs ONLY the amount of time I'd spent on the current task. If this fictional girl has spent 2 weeks organizing her mind and hasn't put it to code yet, she needs to be fired. The most time I would lo
    • Re: (Score:2, Insightful)

      by Gr8Apes (679165)
      There's a difference between fixing a system and coding, or at least coding at the level we're talking about. We're not talking about a 30m script to do something, we're talking man-years of effort generally on really large hard systems. The difference between fixing that DB and writing the DB software in the first place. To say that those are orders of magnitude difference in effort would be minimizing the differences.

      That's not to say that sysadmins don't have a lot on their plate. However, would you rath
    • Re: (Score:3, Funny)

      by mattwarden (699984)
      Finally, a sysadmin with people skills!
    • As a sysadmin, you are somewhere between a software developer and an office admin / secretary. Should you change the toner in the printer or should the office admin? Don't know, don't care. All I know is that has nothing to do with my job, and my boss would be pretty angry if he found out I was billing them software developer rates to change toner.

      You're a sysadmin. In case you forgot, that means you're supposed to administrate the system. (Since when was a printer not part of the network?) You are a suppor
    • Re: (Score:2, Funny)

      by G-funk (22712)
      Suck shit, that's why we're programmers and not IT :)
    • Re: (Score:2, Funny)

      by Anonymous Coward
      Sounds like somebody's got a case of the Mondays...
    • Re: (Score:2, Insightful)

      by Anonymous Coward
      >Why do I see Joel constantly talking about how disturbing it is to "context switch", when sysadmins like myself are expected to handle a dozen or more tasks, most of them "surprise" stuff, daily?

      Because you're a sysadmin, not a programmer. Unlike the latter, you are not expected to be able to focus on just one project, nor is there any need to enable you to do so.
    • by rossifer (581396)

      Why do I see Joel constantly talking about how disturbing it is to "context switch", when sysadmins like myself are expected to handle a dozen or more tasks, most of them "surprise" stuff, daily? Don't tell me "oh, programming is complex"- so are networks.

      But if most of the tasks are small service requests, then it's 100% appropriate to deal with plenty of context switches. If you're not context switching, you're not getting much done. That doesn't mean that context switches don't cost you attention and f

    • Re: (Score:2, Insightful)

      I've been a sysadmin and a programmer. They are completely different jobs.

      Programmers get paid to create something new. "Context switching" (haven't heard it called that before, but I know exactly what is meant by it) is a real performance hit for programmers. This is because you are focussing on difficult, abstract problems, over lengthy periods of time, and you need momentum and no distraction. Interuptions to that effort set you back way more than you would think.

      Sysadmins get paid to make things wor
    • Re: (Score:3, Insightful)

      by miu (626917)
      I've done both jobs, part of being a sysadmin is being a fire-fighter. What you dismiss as programmers being prima donnas is simple division of labor. Here's a hint: if your job requires you to have a beeper then your job is to run around in constant interrupt mode.
    • Look around when you're being shown around your prospective work area. If the printer, copier or fax machine is blinking that it needs paper/toner/reset, you're not walking around in a "high-tech" environment. Developers who can't figure out how to clear a paper jam probably aren't going to be much help when their code won't deploy properly in production, either.

      Real developers know how to reset the printer, because they had to do it a couple hundred times when they were trying to figure out how to encode
      • Actually, the skills required for clearing a paper jam have little in common with the skills required for software development. BTW, Xerox use to flag paper jams when the program crashed. So now you know why you can't always find the paper to clear.
        • Actually, the skills required for clearing a paper jam have little in common with the skills required for software development.

          Actually, the ability to look into the inner workings of a failed system and determine the cause of failure and effect a solution are pretty primary to software development (as opposed to writing code, which is only a part of SD). Unless you want to be a junior coder forever, so you can ignore integration and deployment issues ("If the architect had done his job right, this wouldn'

          • "Actually, the ability to look into the inner workings of a failed system and determine the cause of failure and effect a solution are pretty primary to software development (as opposed to writing code, which is only a part of SD). "

            True, but the "inner workings" of software have little in common with those of a copier. That's why copier repair experience isn't considered a qualification for software development.

            "Unless you want to be a junior coder forever, so you can ignore integration and deployment issu
            • the "inner workings" of software have little in common with those of a copier

              Gee, y'think? I didn't say that learning copier repair would make you a better programmer, I said that the ability to effectively analyze unfamiliar systems was an important skill for developers to have.

              I guess you forgot to say "Unless one wants"

              Nope, I was using the generic you. Using "one" as a pronoun always sounds stilted and artificial to me, but whatever floats your boat (sorry, "floats one's boat").

              I apologize if you felt

              • Gotta love that revisionist history:

                "Developers who can't figure out how to clear a paper jam probably aren't going to be much help when their code won't deploy properly in production, either"

                Remember the discussion wasn't about "important skills for developers", it was about the difference between the role of an Admin and a developer. It was you who first suggested a link between a copier and development skills, which you're now backing away from.
                • Remember the discussion wasn't about "important skills for developers", it was about the difference between the role of an Admin and a developer

                  No, the side discussion I started was about developer skills (or at least an indicator thereof). I thought the changed subject was clearly indicative; clearly, it was not (to everyone). I was just offering an observation triggered by the "programmers need to stop behaving like prima donnas" comment in the parent. In the future, I'll be sure to flag things more cl

                  • "To tie this in with the parent thread, I'll offer up the additional observation that one trait that good developers and good admins share is the itch to fix a broken system, whether it's a borked XML schema or a misconfigured router."

                    Good developers don't necessarily have an "itch to fix a broken system" but to design a system that isn't broken.

                    "You can't seem to make the connection that clearing paper jams is an application of the ability to perform failure analysis. If you can't analyze the failure mode
    • by mpcooke3 (306161)
      Back in the dark ages of software development programmers had to context switch and the switch costs businesses dearly in terms of wasted developer time. For example a small problem like an important client not being able to access a website could distract many developers for hours. It would start with a small networking issue before lunch then after lunch a client would phone up and tell you your website had given him a virus then another couple of problems happen and before you know it almost the entire t
  • by johnlcallaway (165670) on Monday November 20, 2006 @03:47PM (#16919440)
    When a project goes to production, the team must remain with it for a period of N days to handle the deployment problems. One would expect the majority of issues occur within the first couple of days, maybe weeks. Since it is fresh in their minds, they are the ones best suited to correcting issues. Other projects can be available, but fixing the prior one needs to be priority.

    Then, find the developers who are good at maintenance programming. I hate working on long projects with the associated paperwork and spending long hours working with the customer trying to tweak a table. Even Scrum requires some process work outside of development. I prefer maintenance programming that gives me a chance to know many, many systems at a high level and then dig into them when there is a problem. This lets me contact Susie for a 5 minute discussion, and then her get back to her project. There are fewer processes because the fix is often smaller, and it has to be done now. It's amazing how many processes get circumvented when customers can't use an app.

    The advantage is you get staff members who may not know the deep details of individual products, but have more information about multiple products and are not tied to specific resource timelines. Plus you get developers with timelines who get fewer interruptions. I agree that context switching is bad, whether you are a sys admin or developer. Finding ways to reduce it, even if the solutions means I spend four hours fixing it instead of two, can have other benefits. For instance, being able to say 'Hmm...we had a similar problem last month on this other application, I wonder if it is a similar problem.' then asking the developer a specific question.

    It's a different mindset, and it's not for everyone. People who do it have to be able to juggle multiple priorities and handle context switching well. They also need to be able to 'see the big picture' more clearly and understand how product A works with product B in detail (since many issues often fall there and result in group A blaming group B and nothing getting fixed.)

    They also have to contain their ego and find the challenges in maintenance programming that are just as rewarding as new development. I love being 'the hero' by solving production problems quickly when no one else can.
    • by inKubus (199753)
      All programming is maintenance programming sometimes. Especially when the business lacks core processes. A lot of times even new development will be redone 3-4 times just to satisfy everyone. And new software enevitable spurns inspiration in people, which means new processes which means new development. I prefer the evolutionary model, as in "What is the very least we can do right now?" and do it. Usually that means writing the "program" on paper for people to do. Say you have a paper file. It's not going
  • Spolsky is pretty insightful on this one, but I don't think I like what he's implying here:

    Being able to do mentally difficult things like context switching makes our product better. This Is Why Programmers Get The Big Bucks.

    For sure, you sometimes need to incur the penalty of "context switching" when customer needs (or any important situation) requires it. But I read that part as suggesting that any programmer who's paid well should expect to be yanked around on a regular basis, putting out one fire

    • by CoderDevo (30602)

      And I'm more than a little worried that managers will perceive Joel's article as an endorsement of such yanking.

      My experience tells me that managers don't need any outside endorsements to feel entitled to yank one of their staff onto an urgent assignment. Besides, managers don't read Joel on Software. If they read anything, it is more likely the article at "Intelligent Enterprise" on A Primer on Metrics [intelligen...rprise.com].

      I agree with Joel. Any professional should be able to manage their time and make themselves available

  • It sounds like his criticism is that agile methodologies do not do enough to permit flexibility among the developers. The problem is that the waterfall model, or other traditional methodologies are even more rigid. Most of them delay the maintenence phase until either the end of the software life-cycle or until a team can be organized to tackle the issue, and are based on the idea that a small problem be fixed with a well-planned overhaul, as opposed to a minor tweak. Which do you think would be more likely

  • Being adaptive doesn't mean responding too all interruptions. Remember, one of the key points of Agile is prioritization. You break down the scope so you can focus... not deviate. If interruption messes up your sprint; its because your prioritization (oh no, change control) is broken.

    By the by, agile = cyclical development = waterfall. :-)
  • The problem is the word: "Agile." It's a loaded word that means different things.

    In terms of "Agile Software Development," it means able to react to customer changes "quickly" and without discarding a large ammount of work. Now "quickly" is another loaded word. In the example article, "quickly" basically seems to mean "after the end of a 2-week development cycle, and before the next one."

    Now, in TFA, they're asked to do something that may cause a customer to purchase. This request comes in during a 2-we

  • by Aron S-T (3012) on Monday November 20, 2006 @06:33PM (#16922048) Homepage
    There is no such thing as Agile software. And it is completely ignorant to say "we use Agile". Agile is just an umbrella term for a whole bunch of software development methods. You can say we use Extreme Programming or Scrum or whatever.

    In any case, the discussion between Joel and Dmitri has little or no relationship to the relative merits of Agile methods. Dmitri is just some relatively unknown consultant/guru and his individual opinion is just that. In fact, Joel didn't seem to be dissing Agile methods in general, at least not the way I read it. He is dissing Dmitri's doctrinaire approach.

    Moreover, the whole discussion is far from illuminating since it is based on a totally hypothetical example. Give me a real world and specific example where we can get a concrete view of what the real priorities and politics of the situation are, and then we can form an opinion on how to behave. Dmitri in his response to Joel talks about
    "trust." But if the customer involved is critical to the company, you can be sure as hell that the project manager would (justifiably) get his ass kicked if he ignored the sales request and got all touchy feely about "trust." On the other hand if this is some nundik sales person then it probably can and should be managed by the project manager.

    Ultimately, Agile is all about human-centric. As such, you need to understand that organizational politics and behavior can be just as important to the success of a software project as the programming language you choose. Both Joel and Dmitri seem to be ignoring that.
  • by samael (12612) * <Andrew@Ducker.org.uk> on Monday November 20, 2006 @06:35PM (#16922072) Homepage
    He's not saying "We won't do it." - he's saying "The coder should carry on with their job until a proper decision is made as to whether the context switch is worth it." - he clearly says that the decision as to whether to change what the developer is doing is passed over to the Project Manager to make.

    And that sounds right to me. You don't context switch based on getting an email, and you make sure that project managers understand the implications of what they're asking for before you start working on it.
  • Opportunity Cost (Score:3, Informative)

    by MagikSlinger (259969) on Monday November 20, 2006 @06:42PM (#16922174) Homepage Journal
    For those of us with even a little economics background recognizes Joel's post as a discussion on opportunity cost [wikipedia.org].
  • Sure, if you let the inmates run the asylum, you get some ... strange decisions.

    The bottom line is that mindless adherence to any rule, even a rule that is supposed to ensure you are more flexible, is bound to make you inflexible.

    If you walk in the rain without an umbrella, you will experience wetness. If you tolerate obstructionism, you will experience obstructions.

    By way of demonstration I was reading recently about the Privacy Act, a US law which supposedly limits what Federal agencies can do with perso
  • If you're constantly switching context, someone messed up. Big time.

    I work in a totally different business, a newspaper office to be exact, and sometimes it seems like all I do is switch context. And it's always because someone fucked up. Every time. Maybe someone forgot to tell our department that there was a publication going to print today. Or maybe someone forgot to turn in the paperwork for an ad that runs tomorrow and they need the proof right now. Or maybe they're just idiots and have to explai
  • Sounded nice (Score:4, Interesting)

    by bataras (169548) on Tuesday November 21, 2006 @12:32AM (#16925276)
    It sounded nice to hear Joel debunk the agile anecdote as anti-agile and then offer his own real world example.

    Problem is his example leave his own "agile" slip showing a bit. His example is as follows:

    MS released IE7
    This broke a proxy server DLL thingy
    Which in turn broke their own Copilot app for a few customers
    Which meant he had to divert Ben from a 2 week release, fix the problem, patch the server and delay the release
    And this interruption of their agile development was the right decision because it served the customer better

    Setting aside the issue of an individual programmer (Ben) deploying fixes straight to production, here's the thing Agile-Ben should have asked: "how the hell did we let the big IE7 release come along, hoze some of our users, interrupt me and probably cause the next release to be delayed?"

    Assuming it wasn't part of Ben's agile programming job to regression test and qualify major platform changes for released products, Ben should be saying, "screw this 'it was the right decision to interrupt you' idea. We shouldn't be in the this place to begin with."
  • It's short and to the point...

    "Agile isn't.."
  • Following is the Agile Manifesto:

    We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan

    That is, while there is value in the items on the right, we value the items on the left more.


    Hmmmm... How does that relate to the article. First, consider t

"Kill the Wabbit, Kill the Wabbit, Kill the Wabbit!" -- Looney Tunes, "What's Opera Doc?" (1957, Chuck Jones)

Working...