• Robert (unregistered) in reply to mhvelplund
    mhvelplund:
    I'm not saying Dave wasn't a wet behind the ears little .... that needed to earn his keep before he started telling people to do things different. I'm just saying, Ben could easily have been the villain from a different perspective :)

    I appreciate the Devil's Advocate stance, but I really can't see how Dave could have possibly been the good guy, no matter what perspective the story was written from. All his work over 2 years literally accounted to less than nothing. If he'd been a douchebag who succeeded in improving the system despite everyone hating him, you'd have a leg to stand on.

  • Herr Otto Flick (unregistered) in reply to Kensey
    Kensey:
    The dirty little secret of all the coding fads like Agile and XP is this: no technique on earth can make bad programmers into good programmers. Only becoming a good programmer can. And if your team is made of good programmers, it doesn't much matter which technique(s) they use, as long as they're all in sync together.

    +1

    However.

    The issue is not that good programmers produce good code and bad programmers produce bad code. In real life, you don't have a team of good programmers, unless you work somewhere totally awesome. Instead, you have a team of "good enough to hire at the rates we pay" programmers. Some of them may have only appeared to be good enough to hire at interview.

    You'll usually have some junior programmers in there as well. The juniors may be good programmers, they may be bad programmers, but they will almost always think that they are excellent programmers.

    Therefore, the best development practices are to use are those that mitigate the "bad" aspects of your team. This impinges on the productivity of your "good" developers, but doesn't help your "bad" developers be productive/not fuck your project in the ass.

    Herr Flick

  • Ken (unregistered) in reply to Robert

    I think it speaks even more to how pathetic Dave is if he couldn't - in two years! - improve on a "system" made entirely of batch files.

  • Jay (unregistered) in reply to Scrummy
    Scrummy:
    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.

    Maybe so. But then, you could say the same thing about pretty much any methodology. That's the point. If your team is made up of the lazy and incompetent and they have never been able to deploy a working system, switching to a different methodology is not likely to solve the problem.

    "Here we use the Dawkins System Development Methodology: We have programmers randomly bang on the keyboard while blindfolded."

    "Hmm, but that doesn't seem to be working very well. None of your programs even successfully compile, never mind produce the desired output."

    "Well, that's just because the programmers aren't randomly banging on the right keys. If only they did it right, it would work."

  • Jay (unregistered) in reply to Bartholomew Taps
    Bartholomew Taps:
    I suppose Russia and China weren't doing communism correctly.

    Exactly! I think it's very unfair to say that communism and socialism are bad ideas just because every time they have been tried they result in poverty and tyranny. The problem is just that we have never had the right people doing them. All we need for socialism to work is the right kind of people. Namely:

    -- People who will work just as hard for abstract ends like "society" as they will for themselves and their own families.

    -- Politicians who are dedicated to the good of the country over their own political careers.

    -- Bureaucrats and regulators who know more about how a particular industry works after reading a book about it than the people who have spent their whole lives working in this industry now. (Well, more likely the regulator quickly skims a book about it -- regulators are busy people.)

    -- Leaders who get no personal satisfaction from political power, but use it only as a tool to further noble goals.

    -- Economists who can make the economy run the way we wish it worked rather than in accordance with the laws of physics.

    That's all it would take!

  • Scrummy (unregistered) in reply to Jay
    Jay:
    Scrummy:
    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.

    Maybe so. But then, you could say the same thing about pretty much any methodology. That's the point. If your team is made up of the lazy and incompetent and they have never been able to deploy a working system, switching to a different methodology is not likely to solve the problem.

    "Here we use the Dawkins System Development Methodology: We have programmers randomly bang on the keyboard while blindfolded."

    "Hmm, but that doesn't seem to be working very well. None of your programs even successfully compile, never mind produce the desired output."

    "Well, that's just because the programmers aren't randomly banging on the right keys. If only they did it right, it would work."

    Phase 1: Make unsubstantiated claim ("you could say the same thing about pretty much any methodology") in an attempt to generalize the problem. Phase 2: ??? Phase 3: Profit (?)

    The difference between your Dawkins method (never heard of it, and I don't think it would work very well) and Agile is that Agile is an empiricism-driven framework. The migration to Agile is no accident. It has been proven, time and again, in large companies and small, to drive real results, and real value. So if there exists an established pattern for success, and someone who fails deviates from that pattern, the pattern is not to blame.

  • Dan Thompson (unregistered) in reply to Scrummy
    Scrummy:
    Remy Porter:
    That's a really lousy thing to say, though.

    "Agile didn't work!" "Then you did it wrong!"

    That said- Agile is a good way to get a team in sync. It's not a project management technique, it's not even a "coding fad"- it's how you organize a team and keep them headed in the same direction.

    Maybe it's not nice to say/hear, but the truth often hurts. If you can't succeed with a proven methodology, it's probably not the methodology that is the problem.

    I guess you're right. I'm planning on using a sledgehammer to sculpt a statue, but somehow whenever I try it keeps turning out all wrong. Since the sledgehammer is a proven hammer, my mistake must be that I haven't properly applied it to the stone.

  • Pinkerton (unregistered)

    Wow, I like Agile, but all this fawning over a methodology here is downright sickening.

    +1 to all the critiques.

  • ur (unregistered) in reply to Paul
    Paul:
    <snip> as the non-producer class grows, it steadily gobbles up the "evil" "greedy" producers until they are drained and gone. Eventually the best producers are destroyed and the whole thing gradually begins to collapse on itself.
    Replace "grows" with "grows in power", and I think this describes the crash of 2007/08?
  • Bartholomew Taps (unregistered) in reply to Scrummy
    Scrummy:
    Jay:
    Scrummy:
    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.

    Maybe so. But then, you could say the same thing about pretty much any methodology. That's the point. If your team is made up of the lazy and incompetent and they have never been able to deploy a working system, switching to a different methodology is not likely to solve the problem.

    "Here we use the Dawkins System Development Methodology: We have programmers randomly bang on the keyboard while blindfolded."

    "Hmm, but that doesn't seem to be working very well. None of your programs even successfully compile, never mind produce the desired output."

    "Well, that's just because the programmers aren't randomly banging on the right keys. If only they did it right, it would work."

    Phase 1: Make unsubstantiated claim ("you could say the same thing about pretty much any methodology") in an attempt to generalize the problem. Phase 2: ??? Phase 3: Profit (?)

    The difference between your Dawkins method (never heard of it, and I don't think it would work very well) and Agile is that Agile is an empiricism-driven framework. The migration to Agile is no accident. It has been proven, time and again, in large companies and small, to drive real results, and real value. So if there exists an established pattern for success, and someone who fails deviates from that pattern, the pattern is not to blame.

    Obviously those projects that produced real results and drove real value weren't using agile properly.

  • Yoo Suk (unregistered)

    Imperial pig-dog "Dave" work 2 years still software no worky!! Ananannananananna!! Typical stupid ammerikan pwogwammer!!!!! AANNANANANNANANANAN!!

  • Jay (unregistered) in reply to Scrummy
    Scrummy:
    Jay:
    Scrummy:
    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.

    Maybe so. But then, you could say the same thing about pretty much any methodology. That's the point. If your team is made up of the lazy and incompetent and they have never been able to deploy a working system, switching to a different methodology is not likely to solve the problem.

    "Here we use the Dawkins System Development Methodology: We have programmers randomly bang on the keyboard while blindfolded."

    "Hmm, but that doesn't seem to be working very well. None of your programs even successfully compile, never mind produce the desired output."

    "Well, that's just because the programmers aren't randomly banging on the right keys. If only they did it right, it would work."

    Phase 1: Make unsubstantiated claim ("you could say the same thing about pretty much any methodology") in an attempt to generalize the problem. Phase 2: ??? Phase 3: Profit (?)

    The difference between your Dawkins method (never heard of it, and I don't think it would work very well) and Agile is that Agile is an empiricism-driven framework. The migration to Agile is no accident. It has been proven, time and again, in large companies and small, to drive real results, and real value. So if there exists an established pattern for success, and someone who fails deviates from that pattern, the pattern is not to blame.

    Hmm, do I really need to substantiate the claim that "you could say the same about any methodology"? Really?

    So you're saying that Agile is the ONLY methodology in the history of IT that -- if done properly -- results in producing a quality product. Before Agile was invented, there was no such thing as a "successful IT project", and today only teams using Agile produces working system?

    Maybe Agile is the best methodology ever invented. We could debate that. But it's certainly not the ONLY viable methodology.

    Therefore, I stand by my original statement: You could say of many, many methodologies that if the project failed, it's not the fault of the methodolgy, but that they didn't do it right.

    Does it really follow that a totally incompetent team would suddenly start batting 1000 if they switched to using Agile? I really, really doubt it. Some methodologies are better than others, but I have yet to see one that's a magic cure-all.

  • Mr.Bob (unregistered) in reply to Scrummy
    Scrummy:
    This is why you don't let a person or team just go into a hole and write a bunch of code for several months. I can't stress enough how Agile development would have mitigated this process. When you work in small sprints, it guarantees that you will get a complete product that works, with documentation.

    Yes, you are guaranteed a positive result with Agile, no matter the time or cost.

  • Trollface.jpg (unregistered)

    I think the question everyone wants to know is: Who would win, Nagesh or Yoo Suk?

    Captcha: Plaga. A plaga pon both your houses

  • James (unregistered) in reply to Stev

    LOL, I agree. This is yet another reason why I prefer stories with actual code in them, it makes it easier to tell if the teller of the story or the subject of the tale, who is the real 'tard.

  • (cs)

    In a scene out of a crappy romantic comedy, Ben eyed the slick-looking but high-maintenance girlfriend left behind by Dave. Then he turned to the homely-but-sweet high-school sweetheart he had known for years- the batch scripts.

    Yeah, comparing software systems to people is totally not degrading for the latter.

  • Mike (unregistered)

    It's Ben's fault for letting this guy do whatever he wanted.

  • Craig "Dave" David (unregistered) in reply to PiisAWheeL

    -1 for inappropriate use of "appropriate use of irony"

    An "accident" wouldn't be ironic, it would just be a lie. It may be ironic if he actually had an accident, but only mildly. There is some irony in the use of the word "quotes" to mean quotation marks rather than the actual quotations in a sentence containing quotes.

    "and chilled on Sunday." - a quote from a song

  • Cbuttius (unregistered)

    Maybe we all have different opinions as to what Agile means. Possibly based on experiences of companies we have worked where we have tried using it.

    As far as I see it, Agile is a development process, not a programming fad.

    The primary thing that distinguishes Agile is the concept of sprints. Yes, it contains many other parts but sprints is what makes it agile.

    It's a process that lets business analysts do business analysis, designers design, coders write code and testers test.

    It means programmers can spend most of their time writing code, not sit around waiting for specs to be signed off.

    It means you can take a step in what you think is the right direction then meet again to reassess rather than plan everything up front then have to go through a major change control system when either requirements change or you see your original plan was not as perfect as you thought it was.

    Used properly, Agile is a far better development process than what went before it.;

    It does require proper communication however. And proper effective management.

Leave a comment on “Batch of Trouble”

Log In or post as a guest

Replying to comment #:

« Return to Article