Batch of Trouble

« Return to Article
  • ParkinT 2012-06-06 08:04
    A whole chapter of begats was required to trace the roots of the system.


    I like this! A tinge of very familiar pain struck me as I read it.
  • KattMan 2012-06-06 09:07
    I prefer bagets to begats.
    They don't leave such a bad aftertaste and cost less.
  • bob 2012-06-06 09:07
    almost frist
  • KattMan 2012-06-06 09:08
    I do have to wonder though, did no one have to validate the new system beyond his demo of it?
  • serguey123 2012-06-06 09:10
    Hahahhaah, good joke Kattman!
  • beorn 2012-06-06 09:17
    so why did they let him change a working well documented system?
  • KattMan 2012-06-06 09:18
    serguey123:
    Hahahhaah, good joke Kattman!

    Not sure which one you consider the joke around here, the begats or the validation.

    :)
  • Not Nagesh 2012-06-06 09:20
    Really? Management (which actually does have a purpose) let this guy run amok for two years without any evaluation of what he was doing? Typical University IT team perhaps. I never worked on one, but have only heard stories. In the end, maybe everyone got what they deserved.
  • hymie 2012-06-06 09:29
    It seems that things weren't going so well at Dave's new job. A month later he called, hoping that they might need a little more consulting help. "I've got a lot of free time, now," he said.

    *snif* I love a happy ending.
  • Finagle 2012-06-06 09:44
    beorn:
    so why did they let him change a working well documented system?

    Murphy's Laws of Computer programming, Rule #9: "If a program is useful, it will have to be changed."
  • PiisAWheeL 2012-06-06 09:52
    beorn:
    so why did they let him change a working well documented system?
    That wasn't their goal. It seems like they just hired him on and let him do whatever he wanted with little to no accountability. But it went unnoticed because he was such an annoying prick that everyone figured if he wasn't bothering them they could get some work done.
  • Mike D. 2012-06-06 10:02
    KattMan:
    I do have to wonder though, did no one have to validate the new system beyond his demo of it?

    Everyone else was doing Real Work (TM) and had no time for that. However, this overhaul is what Dave was hired to do, and they would be throwing away two years of paying him if they didn't deploy it, so ...
  • Mike 2012-06-06 10:10
    Actually, the article never said that is what he was hired to do. He just took it upon himself to do the rewrite because he thought he could apply a little "I can do it better".
  • Code Slave 2012-06-06 10:18
    You know, I'm honestly surprised that Dave didn't just turn off the old batch files. I really expected him to delete them, and then search out any backups and delete them as well, and rifle through all the previous begatters offices to purge any possible paper copies.
  • ur 2012-06-06 10:24
    Mike D.:
    KattMan:
    I do have to wonder though, did no one have to validate the new system beyond his demo of it?

    Everyone else was doing Real Work (TM) and had no time for that. However, this overhaul is what Dave was hired to do, and they would be throwing away two years of paying him if they didn't deploy it, so ...

    Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?
  • Stev 2012-06-06 10:35
    beorn:
    so why did they let him change a working well documented system?


    If it ain't broke, fix it until it is.

    Seriously though, I do hate the whole notion of "if it ain't broke, don't fix it". There's some truth to it, but frankly if we all took that approach, we'd never invent anything - including the computer. We used candles for hundreds of years, they were simple and they "just worked". Sure, they occasionally set things on fire but so does the modern lightbulb (well, possibly not the energy saving ones).

    The point is, if there's a better way to do something then you should probably do it, but that also means you should do the doing part better as well. Get a list of bullet points of the proposed and the old system, deciding what the pros and cons are. Does the old system have a lot of cons? Then an upgrade is due. Does the new system have a lot of cons? Then scrap it and try again.

    These kind of antics hold everyone back. A good, solid design with a good testing process would have made the new system 10x better than the old system but instead, 10 years down the line when Batch scripts suddenly no longer work (Change of OS? NEW OS? Overzealous security software?) they'll be stuck on either outdated systems or scrambling to get something half as good up ASAP.

    Planning. Do it.
  • Scrummy 2012-06-06 10:36
    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.
  • verisimilidude 2012-06-06 10:43
    ur:

    Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?

    Depends on the language you use. Perl - real quick but maintenance will be tough. Python - Not as quick but maintainable. Java - Not quick and if not done well totally unmaintainable. Visual Basic 6 - Well, maybe that's what he used. It would explain the two years, lack of error handling, and inability for anyone else to pick up the system.
  • KattMan 2012-06-06 10:44
    Stev:
    beorn:
    so why did they let him change a working well documented system?


    If it ain't broke, fix it until it is.

    Seriously though, I do hate the whole notion of "if it ain't broke, don't fix it". There's some truth to it, but frankly if we all took that approach, we'd never invent anything - including the computer. We used candles for hundreds of years, they were simple and they "just worked". Sure, they occasionally set things on fire but so does the modern lightbulb (well, possibly not the energy saving ones).

    The point is, if there's a better way to do something then you should probably do it, but that also means you should do the doing part better as well. Get a list of bullet points of the proposed and the old system, deciding what the pros and cons are. Does the old system have a lot of cons? Then an upgrade is due. Does the new system have a lot of cons? Then scrap it and try again.

    These kind of antics hold everyone back. A good, solid design with a good testing process would have made the new system 10x better than the old system but instead, 10 years down the line when Batch scripts suddenly no longer work (Change of OS? NEW OS? Overzealous security software?) they'll be stuck on either outdated systems or scrambling to get something half as good up ASAP.

    Planning. Do it.


    You're new here aren't you?
  • Ken B. 2012-06-06 10:56
    ur:
    Mike D.:
    KattMan:
    I do have to wonder though, did no one have to validate the new system beyond his demo of it?
    Everyone else was doing Real Work (TM) and had no time for that. However, this overhaul is what Dave was hired to do, and they would be throwing away two years of paying him if they didn't deploy it, so ...
    Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?
    There's a difference between "batch files" and ".bat files".
  • KattMan 2012-06-06 11:03
    Ken B.:
    There's a difference between "batch files" and ".bat files".


    Reality and commen knowledge (let's not call it sense because that isn't common) are not the same. More often than not, I have heard Dos Bat files simply called batch files and in this context I would tend to relate them the same, if only to add to the WTFery.
  • Steve The Cynic 2012-06-06 11:03
    Stev:
    We used candles for hundreds of years, they were simple and they "just worked". Sure, they occasionally set things on fire but so does the modern lightbulb (well, possibly not the energy saving ones).

    Read your history a bit more carefully. Candles had far less "just worked" about them than you think. Compared to even a feeble 40W "candle" bulb, they are dim and produce a murky yellow-orange light. They mark the ceiling with a smoky residue, and that's the best of them. Tallow candles are even dimmer, produce more smoke, and must be trimmed regularly or they will go out. And candles set things on fire a *lot*.

    By comparison, electric light bulbs are almost zero-maintenance, very much brighter, don't flicker or blow out in windy conditions, are smoke-free, and cause fires only rarely.
  • nB 2012-06-06 11:04
    Stev:


    If it ain't broke, fix it until it is.

    Seriously though, I do hate the whole notion of "if it ain't broke, don't fix it". ...We used candles ...

    The point is, if there's a better way to do something then you should probably do it,
    The adage doesn't apply to a new widget. It applies to a single instance of a widget.
    I have a machine. It runs fine and it ain't broke, thus I should not attempt to fix it. As to the Candles, developing a working lightbulb by candlelight so that you no longer need candles is perfectly fine. If your bulb doesn't work you still have candles. This particular DWTF is actually fairly close to that since they still had the old system.
    -nB
  • nB 2012-06-06 11:05
    verisimilidude:
    ur:

    Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?

    Depends on the language you use. Perl - real quick but maintenance will be tough. Python - Not as quick but maintainable. Java - Not quick and if not done well totally unmaintainable. Visual Basic 6 - Well, maybe that's what he used. It would explain the two years, lack of error handling, and inability for anyone else to pick up the system.
    LISP inline'd in c++?
  • snoofle 2012-06-06 11:09
    verisimilidude:

    Depends on the language you use. Perl ... Python ... Java .. Visual Basic 6
    Not necessarily. Anything, including Perl, can be used to write a clear, comprehensible, well documented and maintainable program. Anything, including all of the above, and everything else, can be used to write an incomprehensible undocumented steaming pile of unmaintainable wtf.

    It's the carpenter; not the hammer that makes the difference.
  • airdrik 2012-06-06 11:10
    verisimilidude:
    ur:

    Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?

    Depends on the language you use. Perl - real quick but maintenance will be tough. Python - Not as quick but maintainable. Java - Not quick and if not done well totally unmaintainable. Visual Basic 6 - Well, maybe that's what he used. It would explain the two years, lack of error handling, and inability for anyone else to pick up the system.

    But if you use java, that means that you're going to be using xml and xml (especially java with xml) means enterprizy, and we all know that you should go for the enterprizy systems over the non-enterprizy systems, so he must have been using java and xml.
  • pjt33 2012-06-06 11:11
    verisimilidude:
    ur:

    Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?

    Depends on the language you use. Perl - real quick but maintenance will be tough. Python - Not as quick but maintainable. Java - Not quick and if not done well totally unmaintainable. Visual Basic 6 - Well, maybe that's what he used. It would explain the two years, lack of error handling, and inability for anyone else to pick up the system.

    According to the article (I know, I know), it was "a BPM tool".
  • Smug Unix User 2012-06-06 11:11
    Give me a good batch file any day.
  • KattMan 2012-06-06 11:12
    verisimilidude:
    ur:

    Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?

    Depends on the language you use. Perl - real quick but maintenance will be tough. Python - Not as quick but maintainable. Java - Not quick and if not done well totally unmaintainable. Visual Basic 6 - Well, maybe that's what he used. It would explain the two years, lack of error handling, and inability for anyone else to pick up the system.


    So you threw VB in there just because WHY?
    VB showed problems with programmers so much easier because "everyone" could pick it up. It had error handling just like any othe rlanguage, but since "everyone" could program in it they never used it. Problem wasn't the language, but the programmers, VB just made it easier to spot the problems later because it was more easily read.

    Just don't get me started on those "hey I can read this I must be a programmer" types. There are far to many of them still banging on a keyboard thinking they are writting good code.
  • mott555 2012-06-06 11:26
    snoofle:
    verisimilidude:

    Depends on the language you use. Perl ... Python ... Java .. Visual Basic 6
    Not necessarily. Anything, including Perl, can be used to write a clear, comprehensible, well documented and maintainable program. Anything, including all of the above, and everything else, can be used to write an incomprehensible undocumented steaming pile of unmaintainable wtf.

    It's the carpenter; not the hammer that makes the difference.


    Only somewhat true. Some hammers (like Objective-C) have a striking surface made of low-density polystyrene foam, only one claw, and there's a wasp nest attached to the handle. It actually works better if you hold it upside down and use the wasp nest as the striking surface, but that's against the manufacturer's terms of use and they won't let you sell any products made with a hammer used in such a fashion. Unfortunately the company that makes these hammers has an awesome marketing team, meaning a lot of us carpenters get forced to use it because the client says so. And then they wonder why it takes so long to build something.
  • Nagesh 2012-06-06 11:38
    KattMan:
    verisimilidude:
    ur:

    Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?

    Depends on the language you use. Perl - real quick but maintenance will be tough. Python - Not as quick but maintainable. Java - Not quick and if not done well totally unmaintainable. Visual Basic 6 - Well, maybe that's what he used. It would explain the two years, lack of error handling, and inability for anyone else to pick up the system.


    So you threw VB in there just because WHY?
    VB showed problems with programmers so much easier because "everyone" could pick it up. It had error handling just like any othe rlanguage, but since "everyone" could program in it they never used it. Problem wasn't the language, but the programmers, VB just made it easier to spot the problems later because it was more easily read.

    Just don't get me started on those "hey I can read this I must be a programmer" types. There are far to many of them still banging on a keyboard thinking they are writting good code.


    Also, Java ain't being as bad as some scarecrow is saying. Very often I am geting code, however, that needs me massage it to be clean and catching all exception.
  • campkev 2012-06-06 11:39
    the lower the chance of Dave having an "unfortunate" accident

    I think you put the quotes around the "wrong" word
  • beorn 2012-06-06 11:42
    campkev:
    the lower the chance of Dave having an "unfortunate" accident

    I think you put the quotes around the "wrong" word


    It's not actually wrong?
  • ¯\(°_o)/¯ I DUNNO LOL 2012-06-06 11:46
    So what's a BPM tool, anyhow?

    Bowel-like Program Movement?
  • Matt 2012-06-06 11:50
    TRWTF is management not correcting what was obviously a bad hire. It happens - substandard people get hired. The wrong way to deal with it is let them sit in the corner and hope they don't cause too much damage. Only two options: Fix 'em or Fire 'em.
  • Nagesh 2012-06-06 11:58
    #3. Documentation is obvious lie.

    Has anybody here work on complete documented system? I bet Rs 500/- from my next salary slip.
  • neminem 2012-06-06 12:05
    snoofle:
    Anything, including Perl, can be used to write a clear, comprehensible, well documented and maintainable program.


    I agree completely about Perl - while it doesn't necessarily make it as easy to write -large- maintainable applications as some languages, I've certainly seen decent-sized scripts in perl that were entirely pretty and easy to figure out. Perl kinda gets a bad rap just because it makes it so easy to write unreadable garbage if that's what you're trying for. That said...
    http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29
    http://en.wikipedia.org/wiki/Brainfuck
    http://en.wikipedia.org/wiki/INTERCAL_programming_language

    Technically Turing Complete! (Yes, I do know you were actually implying that only about languages that were designed to get work done in them, rather than languages designed intentionally as parodies, but I like nitpicking.)
  • Kensey 2012-06-06 12:11
    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.


    Sure, that sounds good in theory, but I worked with an actual Agile dev team. They turned out plenty of awful code and had a project basically thrown away by the client after months of work because oops, they forgot to gather requirements first! So when they triumphantly unveiled the first demo (that the client knew nothing about), the reaction was "...yeah, this doesn't really work for us, and by the way how much of our money did you spend on this?"

    By contrast some of the very best code I've seen was turned out by single programmers working alone "off in a cave", with a coherent vision and the skills to realize it.

    (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.)
  • Scrummy 2012-06-06 12:15
    Kensey:

    Sure, that sounds good in theory, but I worked with an actual Agile dev team. They turned out plenty of awful code and had a project basically thrown away by the client after months of work because oops, they forgot to gather requirements first! So when they triumphantly unveiled the first demo (that the client knew nothing about), the reaction was "...yeah, this doesn't really work for us, and by the way how much of our money did you spend on this?"

    By contrast some of the very best code I've seen was turned out by single programmers working alone "off in a cave", with a coherent vision and the skills to realize it.

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


    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.
  • russ0519 2012-06-06 12:16
    mott555:
    snoofle:
    verisimilidude:

    Depends on the language you use. Perl ... Python ... Java .. Visual Basic 6
    Not necessarily. Anything, including Perl, can be used to write a clear, comprehensible, well documented and maintainable program. Anything, including all of the above, and everything else, can be used to write an incomprehensible undocumented steaming pile of unmaintainable wtf.

    It's the carpenter; not the hammer that makes the difference.


    Only somewhat true. Some hammers (like Objective-C) have a striking surface made of low-density polystyrene foam, only one claw, and there's a wasp nest attached to the handle. It actually works better if you hold it upside down and use the wasp nest as the striking surface, but that's against the manufacturer's terms of use and they won't let you sell any products made with a hammer used in such a fashion. Unfortunately the company that makes these hammers has an awesome marketing team, meaning a lot of us carpenters get forced to use it because the client says so. And then they wonder why it takes so long to build something.



    You're talking about XCode aren't you?
  • myName 2012-06-06 12:24
    "It wasn't a terribly pretty system, but it did have a few very important features: It worked."

    Sometimes a piece of code will be defended in the comments with this phrase and the poster will be decried, yet it passes unmentioned this time.
  • Jeff 2012-06-06 12:36
    Stev:
    Planning. Do it.
    I plan to.
  • Nagesh 2012-06-06 12:46
    Scrummy:
    Kensey:

    Sure, that sounds good in theory, but I worked with an actual Agile dev team. They turned out plenty of awful code and had a project basically thrown away by the client after months of work because oops, they forgot to gather requirements first! So when they triumphantly unveiled the first demo (that the client knew nothing about), the reaction was "...yeah, this doesn't really work for us, and by the way how much of our money did you spend on this?"

    By contrast some of the very best code I've seen was turned out by single programmers working alone "off in a cave", with a coherent vision and the skills to realize it.

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


    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.


    I endorse this view in full & total.
  • Michael 2012-06-06 12:52
    Having worked at a university in the past, this story is entirely credible. You have to understand how a university is different from a Real Job:

    * The university's money doesn't mostly come from satisfied customers. It comes from vague threats of violence against reluctant taxpayers. So there is no need to show a profit, or a return on investment.

    * Given the lack of motivation to spend the minimum amount of money as productively as possible, managers' self esteem is directly tied to how much money they spend not how much they make for their employer.

    * This means if you have an opportunity to hire someone you do so, in order to build your empire and keep those salary dollars flowing through your hands in future years. It is not important that the employee produce good work inexpensively, since profits and productivity don't matter.

    * By the same rule, you'd never want to fire anyone because that takes you down the ladder a notch. Besides, you can't fire a government employee for anything less than mass chainsaw murder fully recorded by the security cameras. Or hate speech, i.e. saying anything not Politically Correct.

    Under this system (non-capitalism) it is amazing anything works at all.

    But of course capitalism is TRWTF. So what are we to do?
  • Remy Porter 2012-06-06 13:00
    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.
  • Paul Neumann 2012-06-06 13:02
    KattMan:
    Ken B.:
    There's a difference between "batch files" and ".bat files".


    Reality and commen knowledge (let's not call it sense because that isn't common) are not the same. More often than not, I have heard Dos Bat files simply called batch files and in this context I would tend to relate them the same, if only to add to the WTFery.
    Thanks for pointing that out.
  • Paul Neumann 2012-06-06 13:04
    Steve The Cynic:
    <yawn>...
    By comparison, electric light bulbs are almost zero-maintenance, very much brighter, don't flicker or blow out in windy conditions, are smoke-free, and cause fires only rarely.
    Learn abstraction. The comparison being made is that lights ARE more better(TM), but prior to the invention candles were "not broke."
  • Mario 2012-06-06 13:14
    I just laughed out loud in my cube
  • KattMan 2012-06-06 13:24
    Mario:
    I just laughed out loud in my cube

    At least you have a cube.
  • Nagesh 2012-06-06 13:24
    Nagesh:
    Scrummy:
    Kensey:

    Sure, that sounds good in theory, but I worked with an actual Agile dev team. They turned out plenty of awful code and had a project basically thrown away by the client after months of work because oops, they forgot to gather requirements first! So when they triumphantly unveiled the first demo (that the client knew nothing about), the reaction was "...yeah, this doesn't really work for us, and by the way how much of our money did you spend on this?"

    By contrast some of the very best code I've seen was turned out by single programmers working alone "off in a cave", with a coherent vision and the skills to realize it.

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


    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.


    I endorse this view in full & total.

    I also be learning about True Scotsman Fallacy this weekend.
  • UnderSampled 2012-06-06 13:33
    As a result, he started on a Tuesday, and by Wednesday was telling everyone how he would do their job.


    So that's why they never start on Sundays!
  • Yazeran 2012-06-06 13:44
    neminem:
    snoofle:
    Anything, including Perl, can be used to write a clear, comprehensible, well documented and maintainable program.


    I agree completely about Perl - while it doesn't necessarily make it as easy to write -large- maintainable applications as some languages, I've certainly seen decent-sized scripts in perl that were entirely pretty and easy to figure out. Perl kinda gets a bad rap just because it makes it so easy to write unreadable garbage if that's what you're trying for. That said...
    http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29
    http://en.wikipedia.org/wiki/Brainfuck
    http://en.wikipedia.org/wiki/INTERCAL_programming_language

    Technically Turing Complete! (Yes, I do know you were actually implying that only about languages that were designed to get work done in them, rather than languages designed intentionally as parodies, but I like nitpicking.)


    Actually the worst thing I can think of is the 'COMEFROM' command which is actually implemented in some languages....

    Yazeran.

    Plan: To go to Mars one day with a hammer.
  • Scrummy 2012-06-06 14:00
    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.
  • Nagesh 2012-06-06 14:08
    Nagesh (fake):
    Nagesh:
    Scrummy:
    Kensey:

    Sure, that sounds good in theory, but I worked with an actual Agile dev team. They turned out plenty of awful code and had a project basically thrown away by the client after months of work because oops, they forgot to gather requirements first! So when they triumphantly unveiled the first demo (that the client knew nothing about), the reaction was "...yeah, this doesn't really work for us, and by the way how much of our money did you spend on this?"

    By contrast some of the very best code I've seen was turned out by single programmers working alone "off in a cave", with a coherent vision and the skills to realize it.

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


    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.


    I endorse this view in full & total.

    I also be learning about True Scotsman Fallacy this weekend.


    Look like you got link to http://rationalwiki.org/
  • Remy Porter 2012-06-06 14:09
    No, it's stupid to say and hear, because it conveys no information. It assumes its conclusion- that Agile is the right answer.

    It isn't. I'm a huge proponent of Agile methodology, but it's not "a better hammer" and not every problem is a nail. You can't simply say, "well, using Agile teams would solve this problem," because not every organization is suitable for Agile teams to work.

    Agile is one tool for organizing teams, and it's a great tool. But it's not appropriate for every situation, and it sure as hell isn't a panacea for your technological woes.
  • Nagesh 2012-06-06 14:15
    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.


    Scrummy,
    Funny person only. All sarcastic talk just no sarcastic font-face here. Most "proven methodologies" are not real "proven". CMM5 is big farce in our own country.

    Business is business. Manifesto and process driven stuff look good on paper, but real deal is real deal.

    That is ugly truth staring at heart of every programmer.
  • ObiWayneKenobi 2012-06-06 14:46
    Scrummy:
    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.


    QFT. Too many times "agile" translates to "We have no procedures and just do whatever and hope it's right" instead of actual agile which has strict guidelines. And, almost all the time, these faux agile environments love the short development cycles and no upfront requirements, but hate and refuse to use the other parts like pair programming, TDD, constant customer feedback, and all the things that, you know, actually make Agile succeed
  • Jack 2012-06-06 14:53
    Nagesh:
    I also be learning about True Scotsman Fallacy this weekend.

    Why would you risk wasting a clever comment by posting as Fake-Nagesh?
  • Nagesh 2012-06-06 15:00
    Jack:
    Nagesh:
    I also be learning about True Scotsman Fallacy this weekend.

    Why would you risk wasting a clever comment by posting as Fake-Nagesh?

    I ain't being fake imporster. Other Nagesh is ruin in my good name with troling.
  • omar 2012-06-06 15:52
    I hope you told that guy to F_ck off.
  • Coyne 2012-06-06 16:11
    Many a project in the "latest and greatest development environment" has foundered because the "evangelists" have no idea what mission critical means.
  • Oh THAT Brian 2012-06-06 16:11
    COMEFROM? Was that in an unauthorized version of COBOL?

    Seriously, you can have well-documented projects in virtually any language. It all depends on the programmer.

    I remember being given a COBOL program once and was asked to make sense of it. It was apparently a monstronsity that tried to create home-grown ISAM files. It was written as a class project, by managers.

    And I used to have a job where my main responsibility was to examine user's code to find the source of their errors!

    After several days of trying to read this convoluted mess, which include the now-defunct ALTER verb, I admitted defeat. My manager grinned and said that I was not the first to throw in the towel. Several others had tried and nobody could figure out the code. Maybe it was because the code never worked?

    My point: You can have 'self documenting' languages that are impossible to read, or cryptic languages that, if coded by someone who does it well, can be read like a good book.

    A well coded program can be a thing of beauty.
  • PedanticCurmudgeon 2012-06-06 16:19
    Nagesh:
    Jack:
    Nagesh:
    I also be learning about True Scotsman Fallacy this weekend.

    Why would you risk wasting a clever comment by posting as Fake-Nagesh?

    I ain't being fake imporster. Other Nagesh is ruin in my good name with troling.
    You're definitely a real imposter. For starters, you couldn't have known that the True Scotsman Fallacy applied to Scrummy's comment unless you already knew what it was.
  • True Scotsman 2012-06-06 16:23
    PedanticCurmudgeon:
    Nagesh:
    Jack:
    Nagesh:
    I also be learning about True Scotsman Fallacy this weekend.

    Why would you risk wasting a clever comment by posting as Fake-Nagesh?

    I ain't being fake imporster. Other Nagesh is ruin in my good name with troling.
    You're definitely a real imposter. For starters, you couldn't have known that the True Scotsman Fallacy applied to Scrummy's comment unless you already knew what it was.
    You keep pointin' out the obvious an imma give you a true phallus, lad.
  • William 2012-06-06 16:36
    Dave decided to show some initiative, and he fired up a BPM tool and went to work reimplementing their software in it. <!-- In Dave's defense, pretty much all of us have made this mistake at least once. But according to the submitter, Dave was a real jerk about it. -->


    No, Remy, I have never "fired up a BPM tool" in my life, and I hope it stays that way.

    CAPTCHA: "augue" - what thinking about BPM tools gives me.
  • campkev 2012-06-06 16:42
    beorn:
    campkev:
    the lower the chance of Dave having an "unfortunate" accident

    I think you put the quotes around the "wrong" word


    It's not actually wrong?


    Whoosh
  • Gunslinger 2012-06-06 17:01
    Looks like TRWTF is letting him work on this project unsupervised for 2 years with no plan and no interim deliverables.
  • Zylon 2012-06-06 17:04
    Jack:
    Nagesh:
    I also be learning about True Scotsman Fallacy this weekend.

    Why would you risk wasting a clever comment by posting as Fake-Nagesh?

    Same reason he posts as Fake-Nagesh in the first place-- because he's an idiot.
  • Matt Westwood 2012-06-06 17:40
    Michael:
    Having worked at a university in the past, this story is entirely credible. You have to understand how a university is different from a Real Job:

    * The university's money doesn't mostly come from satisfied customers. It comes from vague threats of violence against reluctant taxpayers. So there is no need to show a profit, or a return on investment.

    * Given the lack of motivation to spend the minimum amount of money as productively as possible, managers' self esteem is directly tied to how much money they spend not how much they make for their employer.

    * This means if you have an opportunity to hire someone you do so, in order to build your empire and keep those salary dollars flowing through your hands in future years. It is not important that the employee produce good work inexpensively, since profits and productivity don't matter.

    * By the same rule, you'd never want to fire anyone because that takes you down the ladder a notch. Besides, you can't fire a government employee for anything less than mass chainsaw murder fully recorded by the security cameras. Or hate speech, i.e. saying anything not Politically Correct.

    Under this system (non-capitalism) it is amazing anything works at all.

    But of course capitalism is TRWTF. So what are we to do?


    Sez you. This whole post is political polemic. I'd call you a cunt but you appear to lack the depth and warmth.
  • PiisAWheeL 2012-06-06 18:18
    campkev:
    the lower the chance of Dave having an "unfortunate" accident

    I think you put the quotes around the "wrong" word
    +1 for appropriate use of irony.
    -1 because I think you think it is really wrong word.

    Actually, you can say that he had an "unfortunate" accident, ie an accident that wasn't unfortunate because everyone else wanted him gone, so it would be unfortunate to dave, but fortunate to everyone else. So the quotes give proper irony to that sentence.

    The more popular method (and appropriate to the context of the story) would be an "unfortunate accident" using the whole phrase to indicate that something had been done to him under the guise of an accident, and for the reasons mentioned under "unfortunate" is ironic because its both fortunate to everyone who hates Dave, and was no accident. "How did you get that black eye dave?"... "Uh,... I fell..."

    You could also put the quotes around the word "accident" to indicate that, while what happened to Dave was unfortunate, Dave still "fell".
  • da Doctah 2012-06-06 19:41
    Smug Unix User:
    Give me a good batch file any day.
    DOS prompt FTW!
  • Jack 2012-06-06 19:51
    PiisAWheeL:
    campkev:
    the lower the chance of Dave having an "unfortunate" accident

    I think you put the quotes around the "wrong" word
    +1 for appropriate use of irony.
    -1 because I think you think it is really wrong word.

    Actually, you can say that he had an "unfortunate" accident, ie an accident that wasn't unfortunate because everyone else wanted him gone, so it would be unfortunate to dave, but fortunate to everyone else. So the quotes give proper irony to that sentence.

    The more popular method (and appropriate to the context of the story) would be an "unfortunate accident" using the whole phrase to indicate that something had been done to him under the guise of an accident, and for the reasons mentioned under "unfortunate" is ironic because its both fortunate to everyone who hates Dave, and was no accident. "How did you get that black eye dave?"... "Uh,... I fell..."

    You could also put the quotes around the word "accident" to indicate that, while what happened to Dave was unfortunate, Dave still "fell".

    "Thanks" for that. It's all so "clear" now.
  • anonymous 2012-06-06 21:26
    Of course, it's obvious to me where they went wrong, because I'm so awesome, but the rest of you probably have no idea, so I'm going to tell you.... not because you'll understand, but because it needs to be said!

    2Yrs without so much as a single product review or code review or documentation review or *any* review. If your managers are so inept that they let this happen, then they deserve every single bit of what they got. Bah.

  • Robert 2012-06-06 22:12
    Michael:
    Having worked at a university in the past, this story is entirely credible. You have to understand how a university is different from a Real Job:

    * The university's money doesn't mostly come from satisfied customers. It comes from vague threats of violence against reluctant taxpayers. So there is no need to show a profit, or a return on investment.

    * Given the lack of motivation to spend the minimum amount of money as productively as possible, managers' self esteem is directly tied to how much money they spend not how much they make for their employer.

    * This means if you have an opportunity to hire someone you do so, in order to build your empire and keep those salary dollars flowing through your hands in future years. It is not important that the employee produce good work inexpensively, since profits and productivity don't matter.

    * By the same rule, you'd never want to fire anyone because that takes you down the ladder a notch. Besides, you can't fire a government employee for anything less than mass chainsaw murder fully recorded by the security cameras. Or hate speech, i.e. saying anything not Politically Correct.

    Under this system (non-capitalism) it is amazing anything works at all.

    But of course capitalism is TRWTF. So what are we to do?

    Be careful about your terminology there. You're describing the environment of working at a public university. Don't lump us private university programmers in with that croud, please. I work at Caltech, and it's a glorious job with none of the problems you described.
  • shadowman 2012-06-06 23:43
    KattMan:
    verisimilidude:
    ur:

    Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?

    Depends on the language you use. Perl - real quick but maintenance will be tough. Python - Not as quick but maintainable. Java - Not quick and if not done well totally unmaintainable. Visual Basic 6 - Well, maybe that's what he used. It would explain the two years, lack of error handling, and inability for anyone else to pick up the system.


    So you threw VB in there just because WHY?
    VB showed problems with programmers so much easier because "everyone" could pick it up. It had error handling just like any othe rlanguage, but since "everyone" could program in it they never used it. Problem wasn't the language, but the programmers, VB just made it easier to spot the problems later because it was more easily read.

    Just don't get me started on those "hey I can read this I must be a programmer" types. There are far to many of them still banging on a keyboard thinking they are writting good code.


    I see the VB6 inclusion as appropriate for exactly that reason. The kind of guy that would do those things would probably have VB6 as his go-to tool.

    Anyway, what is a "BPM tool" supposed to mean? Google searches seem to lead to Business Process Modelling, ie flowcharts, etc. Not sure how that translates to a programming language.
  • AN AMAZING CODER 2012-06-07 00:54
    Remy Porter:
    No, it's stupid to say and hear, because it conveys no information. It assumes its conclusion- that Agile is the right answer.

    It isn't. I'm a huge proponent of Agile methodology, but it's not "a better hammer" and not every problem is a nail. You can't simply say, "well, using Agile teams would solve this problem," because not every organization is suitable for Agile teams to work.

    Agile is one tool for organizing teams, and it's a great tool. But it's not appropriate for every situation, and it sure as hell isn't a panacea for your technological woes.


    This is the truth, and I'm also a proponent of agile.

  • AndyCanfield 2012-06-07 01:12
    snoofle:
    It's the carpenter; not the hammer that makes the difference.

    The hammer may not make a difference, but the wood does. Try building a bridge out of particle-board. It just won't carry the weight.
  • George 2012-06-07 02:59
    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.


    There is a middleground between scrum and letting people work unsupervised in a hole.
  • mickeyding 2012-06-07 03:24
    TWTF - "It was thoroughly documented and well understood by the support team"
  • TheRider 2012-06-07 03:29
    Scrummy:
    Kensey:

    Sure, that sounds good in theory, but I worked with an actual Agile dev team. They turned out plenty of awful code and had a project basically thrown away by the client after months of work because oops, they forgot to gather requirements first! So when they triumphantly unveiled the first demo (that the client knew nothing about), the reaction was "...yeah, this doesn't really work for us, and by the way how much of our money did you spend on this?"

    By contrast some of the very best code I've seen was turned out by single programmers working alone "off in a cave", with a coherent vision and the skills to realize it.

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


    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.
    Indeed. How can it be that "oops, they forgot to gather requirements first!" An agile team working correctly is gathering requirements at the beginning of every sprint, every week or two. It is impossible for them to work for months without requirements. And showing it to the customer only after months (after performing many one- or maybe two-week sprints) is TRWTF for an agile team. This tells me they have to learn how agile works first.
  • ochrist 2012-06-07 04:14
    Oh THAT Brian:
    COMEFROM? Was that in an unauthorized version of COBOL?


    No, but it might have been SLOBOL:
    http://neil.franklin.ch/Jokes_and_Fun/Languages_Compete_with_APL

    About COMEFROM, I remember reading an article about it, but can't find the exact reference any more. However this link should point you in the right direction:
    (link no. 2) (referenced in this article:
    (link no. 3) )

    Fuck you, Akismet! My comment is not spam. Get lost. What should I write here to convince you I'm not spamming. Is Akismet really TRWTF? Just asking...
    After the fifth or so attempt, I have removed the links. Hope that helped.
    No, it didn't, so what to do?
    I know it. Disguise the links to look not-link-like (WTF???)
    No, not enough. Maybe remove the links altogether (but they were the whole purpose of my post here)
    Edit: That helped. Now to try reinserting the links again.

    Addendum (2012-06-07 04:22):
    Link no. 2 should be an article about the comefrom statement:
    www.fortran.com/fortran/come_from.html
    and link no. 3 is this small article:
    https://secure.wikimedia.org/wikipedia/en/wiki/COMEFROM
  • blither 2012-06-07 04:49
    Jeff:
    Stev:
    Planning. Do it.
    I plan to.


    Wonderful, thanks :)

    How could they do 'agile' with the guy if he was such a dick? That would have required cooperation.
  • Bartholomew Taps 2012-06-07 05:03
    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.


    It's fine to do this as long as
    (a) the developer is competent and
    (b) the requirements are known

    In this story, there is an existing system to demonstrate the requirements. And of course one should include the "right" kind of flexibility as a requirement if you expect things to change in the future.

    The story here is that the guy is incompetent. And that is the only really compelling argument for requiring him to do iterative/frequent delivery type process.

    But of course somebody else would need to feed him the stories and evaluate the deliveries. And if *they* are incompetent...
  • Bartholomew Taps 2012-06-07 05:18
    snoofle:

    It's the carpenter; not the hammer that makes the difference.


    If that was true, we'd still be banging nails in with our fists. Human beings are tool-makers for a reason.
  • dan 2012-06-07 05:28
    KattMan:
    I prefer bagets to begats.
    They don't leave such a bad aftertaste and cost less.


    Hmmm.... do you mean baguettes?
  • Bartholomew Taps 2012-06-07 05:36
    Scrummy:
    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.


    I suppose Russia and China weren't doing communism correctly.

    Agile appeals to managers who want to get something out quickly to impress their superiors (it is linked to the "responsiveness" trend in management). Followed to the letter, agile will produce quick results initially. But the amount of refectoring, testing and pairing required makes it low on overall productivity. It is, if you like, a low latency/low bandwidth approach. By the time a market-ready or deployment-ready system has been produced, it has adtually taken longer than waterfall.

    What inevitably happens is that managers attempt to offset the low productivity by skimping on refactoring, testing etc. This causes projects to crash into a brick wall of unmaintainability, and productivity disappears completely. The team is reduced to adding trivial features and doing trivial bug fixes.
  • Steve The Cynic 2012-06-07 05:48
    Paul Neumann:
    Steve The Cynic:
    <yawn>...
    By comparison, electric light bulbs are almost zero-maintenance, very much brighter, don't flicker or blow out in windy conditions, are smoke-free, and cause fires only rarely.
    Learn abstraction. The comparison being made is that lights ARE more better(TM), but prior to the invention candles were "not broke."

    I did learn abstraction, many years ago. My point was that candles *were* "broke" in a variety of fairly serious ways (smoky, dim, fire hazard, ...), so using them as an analogy for "if it ain't broke, don't fix it" purposes is of limited value.

  • Hmmmm 2012-06-07 06:42
    Bartholomew Taps:
    I suppose Russia and China weren't doing communism correctly.


    There's many a true word spoken in jest. No country in history has ever got anywhere near being truly communist. Most haven't even got to socialist...

    The main problem I see with agile is that the method is far too sensitive to implementation details, forget (or skimp on) one seemingly little thing and the whole thing switches from being beneficial to being a productivity sapping waste of time...
  • ur 2012-06-07 07:13
    Bartholomew Taps:
    Scrummy:
    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.


    I suppose Russia and China weren't doing communism correctly.

    Stop this subversive backchat or I, the people, will have you shot.
  • Foo 2012-06-07 08:10
    Yazeran:

    Actually the worst thing I can think of is the 'COMEFROM' command which is actually implemented in some languages....

    Yazeran.

    Plan: To COME FROM Earth one day with a hammer.


    FTFY
  • Your Name 2012-06-07 08:23
    Not Nagesh:
    Really? Management (which actually does have a purpose) let this guy run amok for two years without any evaluation of what he was doing? Typical University IT team perhaps. I never worked on one, but have only heard stories. In the end, maybe everyone got what they deserved.

    Trust me, it's not just universities..... The very large corporation I work for does the same thing. My group let an egotistical buffoon completely redesign our old smooth-running, well-documented system from the ground up, because he supposedly "knew better" even with no experience in our app. It was supposed to take 2 years start-to-finish. Now, 4 unsupervised years later, only 25% of the "new system" is complete (in production), and it's slower & buggier than ever. Meanwhile Mr. Ego has moved on to a different project and doesn't want to finish what he started. Truth be told, no one else wants to finish it either.

    Captcha 'commoveo' -- commoveo here, sit down, and finish your damn project!
  • null 2012-06-07 08:35
    pjt33:
    According to the article (I know, I know), it was "a BPM tool".

    Big Pile of Manure?
  • Nagesh 2012-06-07 10:16
    Ain't it being amazing how frequence Alex no post article and still have scarecrow boldnes to call site "daily?"Any amployee I manage would have be massaged severely to be showing that much reckles.
  • KattMan 2012-06-07 10:29
    Nagesh:
    Ain't it being amazing how frequence Alex no post article and still have scarecrow boldnes to call site "daily?"Any amployee I manage would have be massaged severely to be showing that much reckles.


    Once you start paying him, then you can hold him to deadlines.
  • Nagesh 2012-06-07 10:38
    KattMan:
    Nagesh:
    Ain't it being amazing how frequence Alex no post article and still have scarecrow boldnes to call site "daily?"Any amployee I manage would have be massaged severely to be showing that much reckles.


    Once you start paying him, then you can hold him to deadlines.

    I ain't ever click on ads. Scarecrow to have them, if ain't being post article all time.
  • A Gould 2012-06-07 10:40
    myName:
    "It wasn't a terribly pretty system, but it did have a few very important features: It worked."

    Sometimes a piece of code will be defended in the comments with this phrase and the poster will be decried, yet it passes unmentioned this time.


    In the words of my Practical Programming professor (whose only taught night classes because his day job was running the university networks) - "make it work, then make it pretty".

    Or put another way - If it works but it's ugly, it still works.
  • Nagesh 2012-06-07 10:56
    When my contract run out, I am thinking Alex is being donkey-hole and scarecrow for not post article. I ain't be massage his dead body any times soon.
  • Anonymous 2012-06-07 11:16
    Scrummy:
    When you work in small sprints, it guarantees that you will get a complete product that works, with documentation.


    Guarantees it, indeed! Meanwhile, back in the real world...
  • mhvelplund 2012-06-07 12:16
    Isn't it fun how much power you wield when you get to pick the perspective for a story?

    How many people in here have tried having a job at a place populated by people who think source control is a shared usb-key, and who are satisfied with 5000 lines of csh scripts that need to be hand fed to the system because that is the way an unbroken line of ambitionless grognards did it since the asterisk in *nix meant U.

    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 :)
  • Paul 2012-06-07 12:39
    Hmmmm:
    No country in history has ever got anywhere near being truly communist. Most haven't even got to socialist.
    That's because before you get there, everyone is dead.

    "From each according to his strength, to each according to his need."

    Sound like a good idea? It is certainly popular. But it is the ideology of death.

    Every society is composed of only three types of people: producers, beggars, and thieves. Only the producers make the things everyone needs. Beggars talk you into giving them stuff. Thieves just take what they want by violence.

    If there were no producers, there would be nothing for the beggars and thieves to consume. They would die when they ran out of stuff to take from each other.

    Taking -- usually by threats of violence -- from the producers, and distributing to the beggars and thieves, can work as long as the producers are allowed to produce enough for all. But 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.
  • Robert 2012-06-07 12:40
    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 2012-06-07 12:41
    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 2012-06-07 12:52
    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 2012-06-07 13:19
    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 2012-06-07 13:41
    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 2012-06-07 14:51
    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 2012-06-07 19:06
    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 2012-06-07 21:07
    Wow, I like Agile, but all this fawning over a methodology here is downright sickening.

    +1 to all the critiques.
  • ur 2012-06-08 05:12
    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 2012-06-08 06:50
    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 2012-06-08 07:21
    Imperial pig-dog "Dave" work 2 years still software no worky!! Ananannananananna!! Typical stupid ammerikan pwogwammer!!!!! AANNANANANNANANANAN!!
  • Jay 2012-06-08 14:12
    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 2012-06-08 19:00
    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 2012-06-11 13:11
    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 2012-06-11 13:41
    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.
  • lucidfox 2012-06-12 01:21
    > 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 2012-06-12 13:49
    It's Ben's fault for letting this guy do whatever he wanted.
  • Craig "Dave" David 2012-06-13 18:53
    -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 2012-07-02 06:41
    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.