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

  • (cs) in reply to ParkinT

    I prefer bagets to begats. They don't leave such a bad aftertaste and cost less.

  • bob (unregistered)

    almost frist

  • (cs) in reply to KattMan

    I do have to wonder though, did no one have to validate the new system beyond his demo of it?

  • (cs) in reply to KattMan

    Hahahhaah, good joke Kattman!

  • beorn (unregistered)

    so why did they let him change a working well documented system?

  • (cs) in reply to serguey123
    serguey123:
    Hahahhaah, good joke Kattman!
    Not sure which one you consider the joke around here, the begats or the validation.

    :)

  • Not Nagesh (unregistered)

    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.

  • (cs)

    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 (unregistered) in reply to beorn
    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."
  • (cs) in reply to beorn
    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. (unregistered) in reply to KattMan
    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 (unregistered) in reply to Mike D.

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

  • (cs)

    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 (unregistered) in reply to Mike D.
    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 (unregistered) in reply to beorn
    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 (unregistered)

    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 (unregistered) in reply to ur
    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.
  • (cs) in reply to Stev
    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. (unregistered) in reply to ur
    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".
  • (cs) in reply to Ken B.
    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.

  • (cs) in reply to Stev
    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 (unregistered) in reply to Stev
    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 (unregistered) in reply to verisimilidude
    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++?
  • (cs) in reply to verisimilidude
    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.

  • (cs) in reply to verisimilidude
    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.
  • (cs) in reply to verisimilidude
    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 (unregistered)

    Give me a good batch file any day.

  • (cs) in reply to verisimilidude
    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.

  • (cs) in reply to snoofle
    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 (unregistered) in reply to KattMan
    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.

  • (cs)
    the lower the chance of Dave having an "unfortunate" accident
    I think you put the quotes around the "wrong" word
  • beorn (unregistered) in reply to campkev
    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 (unregistered)

    So what's a BPM tool, anyhow?

    Bowel-like Program Movement?

  • Matt (unregistered)

    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.

  • (cs)

    #3. Documentation is obvious lie.

    Has anybody here work on complete documented system? I bet Rs 500/- from my next salary slip.

  • neminem (unregistered) in reply to snoofle
    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.)

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

    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 (unregistered) in reply to Kensey
    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.

  • (cs) in reply to mott555
    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 (unregistered)

    "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 (unregistered) in reply to Stev
    Stev:
    Planning. Do it.
    I plan to.
  • (cs) in reply to Scrummy
    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 (unregistered)

    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?

  • (cs) in reply to Scrummy

    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 (unregistered) in reply to KattMan
    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 (unregistered) in reply to Steve The Cynic
    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 (unregistered) in reply to Jeff

    I just laughed out loud in my cube

  • (cs) in reply to Mario
    Mario:
    I just laughed out loud in my cube
    At least you have a cube.
  • Nagesh (unregistered) in reply to Nagesh
    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.

Leave a comment on “Batch of Trouble”

Log In or post as a guest

Replying to comment #382603:

« Return to Article