• Lego (unregistered) in reply to Blue Note
    Blue Note:
    This is depressing. Are there any good IT jobs out there?

    Yes, ABSOLUTELY!

    The catch is, that they are all located in Bangalore, Hydrabad and Mumbai.

    Apply at HCL, Infosys, Wipro, Cognizant, et al.

    Pretty soon that is where all our IT jobs will be located.

    --Lego

  • imalc (unregistered)

    Perhaps "Learn the Network" translates to "Learn how to hack the network" so that he can then install his new app/front-end/script etc.

  • darkmage0707077 (unregistered) in reply to jpers36
    Addison:
    ...I think TRWTF was that there were hundreds of people willing to work at a crappy job for probably sub-average pay doing something no sane person would find enjoyable in any stretch of the imagination. And when someone tries to improve the situation they are thwarted at every turn.

    The human ability to preserve the status quo never ceases to amaze me!

    Actually, I think the real TRWTF (TRTRWTF) is that this company apparently still had customers for him to "work with" in spite of the (apparently long term) service issues and BS support, and an even bigger TRTRWTF is that he says he was a customer there, but no where does it say that he STOPPED being a customer before or after taking the job...

    Preserving the status quo indeed!

  • BEF (unregistered) in reply to darkmage0707077
    darkmage0707077:
    Actually, I think the real TRWTF (TRTRWTF) is that this company apparently still had customers for him to "work with" in spite of the (apparently long term) service issues and BS support....

    Generally speaking, in these cases there often is no viable alternative.

  • Ogbert (unregistered)

    "....within a few hours had set up a crontab that took care of that whole process by sending mouse clicks, keystrokes, and so on..."

    wat? How the hell does a cron job (i.e. Unix) manage to send mouse clicks and keystrokes?

  • Franz Kafka (unregistered) in reply to SlyEcho
    SlyEcho:
    it would need PerlMagick, a dozen or so Perl modules, Wine, xdotool, a VNC server, lots of config tweaking, the works.

    What would you do if someone wants to put this in your server? And who's going to maintain this Rube Goldberg-like mess?

    Install it, then assign the guy it replaces (and the guy who wrote the script) to do what it takes to eliminate the nasty brittle parts. At the end, you can eliminate Wine and vnc at the minimum. With any luck, it'll be a handful of perl and some ssh keys.

  • Greg (unregistered) in reply to ClutchDude

    The real WTF is how many think this way about IT problems and do not seem to be trolls.

    If the "ugly hack" scripts stop working one day or start malfunctioning, go back to the old way. If there is a week of data cleanup from the malfunction after 6 months, it still saved 5 months and 3 weeks or so of work. If it ruins more then a weeks of data, then there should be better backups and that is a WTF in itself.

    If a new and better system is implemented a year later, the ugly hack scripts have served their purpose and can be discarded at that point. If they fail and no one fixes them [for whatever reason], the employees can go back to the inefficient way of doing things with a net gain from where things started out [of X months of free work being done for them].

    It really just sounds like some narcissists protecting their middle management positions, clamping down on innovation however they can (based on my experience of running into similar issues).

  • (cs) in reply to ClutchDude
    ClutchDude:
    Addison:
    Not if it works. I wouldn't buy a meat slicer if I needed to make a sandwich. I'd pull out a knife and stab away until I had some meat hacked off for my sandwich.
    That works, till one day, while hacking away, your imprecise stabbing misses the mark, enough to stab your hand.
    I thought that was what he meant in the first place. :-P
  • (cs)

    We're missing a crucial piece of information here, which is what exactly was Mike hired to do?

    I'm not making any insinuations about what actually happened, but I'm wondering if this particular process was outside his scope and the company already had more experienced people working on a more efficient and/or robust solution.

    I had that experience once before at a large company, way back when I was a mere summer intern. Came up with some quick report for QC that turned out to be nearly identical to what their "real" programmers had been working on for a year. Now, those programmers were useless, but I can just as easily imagine a situation where a company is 3 months into the implementation of a fairly large system and doesn't want to worry about future compatibility with some clumsy hack.

    Again, not insinuating - just thinking about what the other side of the story might be.

  • (cs) in reply to Greg
    Greg:
    If the "ugly hack" scripts stop working one day or start malfunctioning, go back to the old way. If there is a week of data cleanup from the malfunction after 6 months, it still saved 5 months and 3 weeks or so of work. If it ruins more then a weeks of data, then there should be better backups and that is a WTF in itself.

    Do you really think that the only risk of implementing Mike's solution is ruining a week's worth of data?

  • Patrick (unregistered)

    No disrespect to Mike, but his setup seemed like an equally perverse solution. I dunno what the problem was, but if he's writing a script which uses mouse clicks he's not really fixing anything. I dunno, maybe Mike was as much to blame for this as they were.

  • Rich (unregistered) in reply to SlyEcho
    SlyEcho:
    it would need PerlMagick, a dozen or so Perl modules, Wine, xdotool, a VNC server, lots of config tweaking, the works.

    What would you do if someone wants to put this in your server? And who's going to maintain this Rube Goldberg-like mess?

    Exactly. Just because it sorta works today doesn't mean it's going to work tomorrow. It sounds like he's a bedroom hacker ("he was interested enough to hack away at it while he was at home"), who just wanted to massage his ego ("He filled notepads and whiteboards with DaVinci-esque diagrams of the multi-faceted processes"). Like he was trying to emulate the Microsoft print ads.

    Yes, I've met a few of those. Always complaining about how "bureaucracy" is getting in the way of "real work". And then you get to their code and config. A flimsy house of cards. One version bump and it all falls down. Unauthorized servers on the floor instead of running in a power-managed air conditioned server room.

    It takes months to dismantle these childish contraptions gently, all the while nudging them back into life when they fail, and gradually replace them with more robust documented processes.

    Indeed, what they're really complaining about is accountability.

    Today's hero is no different. I have a sneaking suspicion that Dick's abilities are not really at fault.

  • (cs) in reply to RocketRick
    RocketRick:
    I've seen this same sort of thing far too many times. People like Mike need to realize that automating a bad process doesn't improve anything, it just makes it faster to do the wrong thing.
    There's a rather well-known anecdote about a tire company executive showing off his new multi-million dollar machine that wrapped the freshly made tires in paper. It was a triumph! It did this so much faster than the line workers!

    The person being shown this piece of equipment asked a question. "Why do you wrap the tires in paper?"

    "Because this way the whitewalls aren't scuffed up during shipping."

    "How many whitewall tires do you make any more? Most modern cars don't use them."

    Uncomfortable silence.

    Why is more important than how when it comes to automating stuff.

  • Franz Kafka (unregistered) in reply to Rich
    Rich:
    It takes months to dismantle these childish contraptions gently, all the while nudging them back into life when they fail, and gradually replace them with more robust documented processes.

    Indeed, what they're really complaining about is accountability.

    Today's hero is no different. I have a sneaking suspicion that Dick's abilities are not really at fault.

    This childish contraption is the process documentation. I'm pretty sure Mizzike would be more than happy to install his script, then replace pieces with more robust variants until he's got something industrial grade. In the meantime, the process is automated, so that's one less bit of monkeywork and less errors in the meantime.

  • (cs)
    This childish contraption is the process documentation. I'm pretty sure Mizzike would be more than happy to install his script, then replace pieces with more robust variants until he's got something industrial grade. In the meantime, the process is automated, so that's one less bit of monkeywork and less errors in the meantime.

    Unless you count the monkeywork involved in getting the thing installed on a server with all its myriad prerequisites (some of which will inevitably be forgotten along the way until it croaks and our hero asks "Oh wait, you didn't install XYZ first, did you?" and fed with production data, and tinkering with it when it falls over.

  • morry (unregistered) in reply to Mark
    Mark:
    In this case, documenting how many mh (manhours) the processes are taking, researching any other systems that may be affected by changing this one, the expected number of hours to implement the fix (including debugging), the expected manhours saved (i.e. when will this start paying for itself), how will things be done during the interim - will both systems be run in parallel to ensure the values match - and is that factored into the cost equation? how what happens to any invoices/records in-progress if you have to back out of the process because of some unforseen issue, training and documenting people on the new system, etc.

    Writing code (the fun stuff) is the LAST stage of any project, not the first.

    I've done a few things "for fun", and let me tell you that if I had to do all that up front work, the coding would no longer be fun. It then has become part of my job and holds little additional fascination for me. Most management fails to realize that. Now should most work be done by the process? Damned straight it should. Should all of it be done that way - hell no. Google (if I recall) has set aside 10% of an employee's time to do whatever they're interested in. the HP laserjet was (originally) built outside of the normal process of "propose, analyze, approve, design, create".

  • Tama (unregistered)

    Woooo keystrokes emulation power, the mother of reliable software design!

    Also, who the heck is Wilson?

  • (cs) in reply to Franz Kafka
    Franz Kafka:
    Rich:
    It takes months to dismantle these childish contraptions gently, all the while nudging them back into life when they fail, and gradually replace them with more robust documented processes.

    Indeed, what they're really complaining about is accountability.

    Today's hero is no different. I have a sneaking suspicion that Dick's abilities are not really at fault.

    This childish contraption is the process documentation. I'm pretty sure Mizzike would be more than happy to install his script, then replace pieces with more robust variants until he's got something industrial grade. In the meantime, the process is automated, so that's one less bit of monkeywork and less errors in the meantime.

    "Between the idea And the reality Between the motion And the act Falls the Shadow"

    Of course we can all agree (well, at least us borderline sane commenters) that both of the disgusting hacks described in the OP are, well, disgusting hacks. But they differ in degree.

    There's nothing wrong with scripting a lousy GUI via automated point-n-clicking -- for local consumption. Clearly it's not a universal solution; nor, I would hope, was it anticipated as such. Basically, it's impossible to differentiate from the original monkey-at-a-desk solution, except in the important respect that it allows the monkey free time to masturbate, which I understand is what monkeys do best.

    The Heath Robinson/Rube Goldberg proposal, however, is clearly the product of a diseased mind ... unless it's anonymised.

    And why would the mind be diseased?

    (1) Day after day in a cubicle barnyard will do that to ya. (2) "Obsessing" about that last little detail of the "solution" ... RPC, Wine, SOAP-on-a-Ruby ... that'll do this to ya. (3) The foreknowledge that, even if you come up with a pellucid and bullet-proof twelve-line script in Perl (or VBA, or whatever), some git in Florida will uncover his pimply fat arse for just long enough to shit all over you ...

    Well, it's not an environment that encourages you to do the right thing, is it? And we've all been there.

    As usual, 90% of TRWTF is the comments (I'll leave 10% for Mike, and 0% for the telco, who DGAS anyway).

    I shall now retire to my day job, as the sort of person responsible for cleaning up Mike-style messes after the Mikes.

  • (cs) in reply to Dugeen
    Dugeen:
    There's no need to put (sic) after every malapropism, it interrupts the flow. Don't worry, we won't think that it's you who's saying 'deterrence'.
    He probably put that in there to keep all the grammar nazis hiding under the carpet from crawling out and working themselves into a religious frenzy over it. Maybe it's just me, but that is half the fun of running a popular website - intentionally making mistakes and watching your least favorite users make asses of themselves. I know it always puts a smile on my face.

    Addendum (2009-03-05 15:32):

    Ogbert:
    "....within a few hours had set up a crontab that took care of that whole process by sending mouse clicks, keystrokes, and so on..."

    wat? How the hell does a cron job (i.e. Unix) manage to send mouse clicks and keystrokes?

    It was a ghetto hack. In fact, I'm rather conflicted about this whole story, because I am nearly certain his scripts play all sorts of stupid games with SendKeys/equivalents, etc and would (rightly) be featured on this site if they were discovered by another developer in a production environment. Ugh. What happens if the "automation" system happens to run on a different resolution monitor at some point, or someone moves the ticket tracking window? All hell breaks loose and his dangerous, hacky automation script starts clicking and typing into all the wrong places. Sure, he might fix things for a while, but the fix is a pile of magic, duct tape, and out-and-out bullshit that sounds like it's about to fall over at a moment's notice; if he gets canned or quits at the wrong time (plenty of TDWTF articles like that), it will creak along for YEARS with people cursing at it and wishing they knew enough about it to replace it.
  • (cs)

    If Mike was hired to enter tickets, he should stick to entering tickets. If he wants to practice his programming at the same time, he can write an MMO in his spare time. Then advertise in the right places, and he can make millions. Or so I've heard.

  • ham (unregistered) in reply to FMannan
    FMannan:
    You dont mean AT&T by any Chance :o) ....?
    AQ&V was his ISP, and he knew all too well why they'd gained a reputation for terrible service. Most customers, Mike included, had learned that it wasn't even worth bothering to call and complain about outages anymore.
    Must have been Telus.

    captcha: tristique, like Triscuit? Those are yummy.

  • (cs)

    "Mike asked for the root password for the dev server..."

    "Hi, can I have the root password for the dev server?" "Who are you?" "I'm Mike, the new guy!" "Oh, alright, then. Just make sure you don't do something like type 'rm -rf'."

  • Brett (unregistered)

    The moral is that no company ever hired anybody to save them from themselves. They hired them to shut up and do what they're told to do.

    Just because you have a compelling urge to stand on your desk and shout, "Look!! Everybody!!! We don't just have to be sheep!!" Doesn't mean it's appropriate or that you're going to get warm fuzzies for doing it.

    All companies are dysfunctional because they are created and run by human beings. Anybody who thinks they are doing anything more than prostituting themselves for money is deluded.

    After 35 years, my metric for job satisfaction is whether or not the paychecks bounce. I try to find personal satisfaction in other places than my job.

  • (cs) in reply to pink_fairy
    pink_fairy:
    "Between the idea And the reality Between the motion And the act
    Between the specification And the implementation
    pink_fairy:
    Falls the Shadow"
    I couldn't agree more.
  • Joey Stick Eye Smiles (unregistered)

    "and that he needed a full list of requirements before anything could be changed."

    Gosh, what assholes. They wanted you to actually write down what you wanted to do? Usually, DaVinci-esque scribblings in a notebook are more than good enough.

  • mgb (unregistered) in reply to ClutchDude
    ClutchDude:
    That works, till one day, while hacking away, your imprecise stabbing misses the mark, enough to stab your hand. I bet after that the idea of nice meat slicer or pre-packaged sliced meat sounds really good....great now I want a sammich.

    It's one thing to "throw something" together for the short term with the plan to implement something more solid. This protagonist in this story doesn't seem to see the difference.

    In general, the least precise automated script is still going to perform on par with a bored data entry clerk.

  • Real-modo (unregistered) in reply to stEvil
    stEvil:
    iToad:
    The Amazing Gordo!:
    SlyEcho:
    it would need PerlMagick, a dozen or so Perl modules, Wine, xdotool, a VNC server, lots of config tweaking, the works.

    What would you do if someone wants to put this in your server? And who's going to maintain this Rube Goldberg-like mess?

    Needs .NET

    And XML.

    Mike is currently writing a script to run a script to add another technology to this comment automatically. Soon TDWTF won't need readers, as his contraptions develop self-awareness and post endless bickering comments with inherent self-reference disguised as ironic hypocrisy.

    All you scripts are belong to Mike

    Needs Oracle too.

    (And yes I did read this before quoting it.)

  • Yanman (unregistered) in reply to Blue Note
    Blue Note:
    This is depressing. Are there any good IT jobs out there?

    The ones that require no management?

    Captcha: dolor -- Oh why yes, pain indeed!

  • Charlie (unregistered) in reply to Brett
    Brett:
    After 35 years, my metric for job satisfaction is whether or not the paychecks bounce. I try to find personal satisfaction in other places than my job.

    Most of our day is taken up by getting ready for work, commute to/from work, actually working, or when we're finally home, too exhausted from work to want to do anything but leisure activities (e.g., reading, tv, video games). Work takes up such a huge part of our lives. I don't think I can be happy if I can't find personal fulfillment through my career. What's a programmer like me supposed to do?

  • Franz Kafka (unregistered) in reply to pink_fairy
    pink_fairy:
    I shall now retire to my day job, as the sort of person responsible for cleaning up Mike-style messes after the Mikes.

    See, here's a perfect opportunity to make Mike do that by way of minimal rearchitecture to eliminate sendkeys bogosity and related crap. So maybe v1 doesn't get on a server, but it demonstrates that a computer can do task X, which means task X is monkeywork and therefore should be done by said computer. The implementation is dreck, but that can be changed.

  • Anonymous (unregistered) in reply to Greg
    Greg:
    If the "ugly hack" scripts stop working one day or start malfunctioning, go back to the old way... If a new and better system is implemented a year later, the ugly hack scripts have served their purpose and can be discarded at that point. If they fail and no one fixes them [for whatever reason], the employees can go back to the inefficient way of doing things with a net gain from where things started out [of X months of free work being done for them].

    The problem is that with the "ugly hack" system in place, the employees will catch up their queue of tickets and be able to take on a higher work load. With the processes running more efficiently, management will not add the additional human resources that would be required if the "ugly hack" system were not there. When the "ugly hack" system fails, the employees will become immediately backlogged with work, which may ultimately cause more problems than by continuing with the previous system. Any system which is truly expected to produce an efficiency, or "net gain", needs to be reliable.

  • (cs) in reply to Moss
    Moss:
    "Mike asked for the root password for the dev server..."

    "Hi, can I have the root password for the dev server?" "Who are you?" "I'm Mike, the new guy!" "Oh, alright, then. Just make sure you don't do something like type 'rm -rf'."

    I believe you mean 'rm -rf /'.

    Always good for a giggle. Has it ever happened?

  • (cs) in reply to Franz Kafka
    Franz Kafka:
    pink_fairy:
    I shall now retire to my day job, as the sort of person responsible for cleaning up Mike-style messes after the Mikes.

    See, here's a perfect opportunity to make Mike do that by way of minimal rearchitecture to eliminate sendkeys bogosity and related crap. So maybe v1 doesn't get on a server, but it demonstrates that a computer can do task X, which means task X is monkeywork and therefore should be done by said computer. The implementation is dreck, but that can be changed.

    By me, yes. Thanks so very much.

    Sometimes I wish I were that other sort of contractor. I don't suppose the pay's any better, but at least the result would be satisfying.

  • (cs) in reply to DaveK
    DaveK:
    pink_fairy:
    "Between the idea And the reality Between the motion And the act
    Between the specification And the implementation
    pink_fairy:
    Falls the Shadow"
    I couldn't agree more.
    Which was sort of the point. (Ta, T.S.)

    Can I do a Godwin here? There's no obvious Nazi follow-up to Mr Eliot, but here's a great coda from the same poem ("The Hollow Men," pub. 1928):

    This is the way the world ends This is the way the world ends This is the way the world ends Not with a bang but a whimper.

  • (cs) in reply to pink_fairy
    pink_fairy:
    DaveK:
    pink_fairy:
    "Between the idea And the reality Between the motion And the act
    Between the specification And the implementation
    pink_fairy:
    Falls the Shadow"
    I couldn't agree more.
    Which was sort of the point. (Ta, T.S.)

    Can I do a Godwin here? There's no obvious Nazi follow-up to Mr Eliot, but here's a great coda from the same poem ("The Hollow Men," pub. 1928):

    This is the way the world ends This is the way the world ends This is the way the world ends Not with a bang but a whimper.

    Funny, I always thought that fast food would conquer everything, and the world would end not with a bang, but a Wimpy.(*)

    (*) - Presumably followed immediately by some kind of cosmic coronary.

  • (cs) in reply to stEvil
    stEvil:
    iToad:
    The Amazing Gordo!:
    SlyEcho:
    it would need PerlMagick, a dozen or so Perl modules, Wine, xdotool, a VNC server, lots of config tweaking, the works.

    What would you do if someone wants to put this in your server? And who's going to maintain this Rube Goldberg-like mess?

    Needs .NET

    And XML.

    Mike is currently writing a script to run a script to add another technology to this comment automatically. Soon TDWTF won't need readers, as his contraptions develop self-awareness and post endless bickering comments with inherent self-reference disguised as ironic hypocrisy.

    ITYM "inherent hypocrisy disguised as ironic self-reference", no?
  • moz (unregistered) in reply to Ogbert
    Ogbert:
    "....within a few hours had set up a crontab that took care of that whole process by sending mouse clicks, keystrokes, and so on..."

    wat? How the hell does a cron job (i.e. Unix) manage to send mouse clicks and keystrokes?

    He used xdotools, as mentioned in the article. He'd need an X server (such as xvfb), but he'd need that anyway to run wine and vnc.

    Maybe he did have something which would work fine without supervision, even if the servers he needed for wine and vnc (and anything else the dev server he sabotaged couldn't do by itself) became unavailable at the worst possible time. It doesn't sound like he ever spoke to anyone who was in a position to evaluate his efforts, though.

  • Not as DULL as you (unregistered) in reply to Addison
    Addison:
    And when someone tries to improve the situation they are thwarted at every turn.

    Trying to improve something and actually improving it can be very very different.

    The only Non-WTF thing about this story is that the manager in Florida was smart enough to not let people put random crap on their server without telling anyone.

  • Not as DULL as you (unregistered) in reply to Orclev
    Orclev:
    When Valve is doing design work on a game it doesn't matter what your job in the company is, you can offer suggestions and ideas (and I'd assume if you had the talent write up a proof of concept) and if the other employees like them they'll be used.

    Which is completely different to what Mike did in this article and to what Rob was talking about with the janitor/Google analogy.

    Your Valve example has unqualified people SUGGESTING changes and then presumably the experts go and implement them if they are considered worthwhile. This article has Mike deciding on his own changes and going about implementing them without consulting the people who really know the systems.

  • db (unregistered) in reply to Rob
    Rob:
    His solution has 'ugly hack' written all over it.

    I'm betting that there was some artistic licence involved in the description of the hack by the editor - it probably stopped at a dozen or so perl modules (rounded up to the nearest dozen).

  • Michael (unregistered) in reply to Addison
    Addison:
    He may not have designed an optimal solution, but I would wager a guess that it was faster and easier than any of the better solutions.

    I would wager a guess that you haven't been working in IT for long. If at all.

  • dag (unregistered) in reply to moz
    moz:
    Ogbert:
    "....within a few hours had set up a crontab that took care of that whole process by sending mouse clicks, keystrokes, and so on..."

    wat? How the hell does a cron job (i.e. Unix) manage to send mouse clicks and keystrokes?

    He used xdotools, as mentioned in the article. He'd need an X server (such as xvfb), but he'd need that anyway to run wine and vnc.

    No, you don't need X to run vnc, vnc is an X server. So you can happily run wine and xdotools inside that.

  • dag (unregistered) in reply to Lego
    Lego:
    Blue Note:
    This is depressing. Are there any good IT jobs out there?
    ... The catch is, that they are all located in Bangalore, Hydrabad and Mumbai. ... Pretty soon that is where all our IT jobs will be located.

    I've no idea what these companies do (Infosys rings a bell but I'm too lazy to look the others up) but I somehow doubt that.

    In my experience the interesting IT jobs are the ones at small companies that service a niche market and need to be agile and close to their customers.

    So unless your customers are in Bangalore, Hydrabad and Mumbai. (Coming to think of it, I do know of a company that has customers in some of these places and does interesting work... no I don't work there.)

  • db (unregistered) in reply to pink_fairy
    pink_fairy:
    I believe you mean 'rm -rf /'.

    Always good for a giggle. Has it ever happened?

    I did it once on a linux home machine I was wiping and installing a new distro on just to see what happened. After it got as far as deleting "rm" it complained it couldn't find it to continue deleting. The thing only had 64MB of memory but even then I was suprised it would try to read rm of the disk in the middle of deleting a pile of stuff. I think "ls" was gone as well but echo from the shell let me list what was still there.

    I must have been really bored at the time :)

  • (cs) in reply to Jax
    Jax:
    Quoted for truth.

    Technology doesn't solve people problems.

    The quote is a lie. Try actually quoting next time. (Disclosure: I did the same thing yesterday.)

    all the while juggling torches and yodeling
    Pics or it didn't happen!
  • Franz Kafka (unregistered) in reply to pink_fairy
    pink_fairy:
    Franz Kafka:
    pink_fairy:
    I shall now retire to my day job, as the sort of person responsible for cleaning up Mike-style messes after the Mikes.

    See, here's a perfect opportunity to make Mike do that by way of minimal rearchitecture to eliminate sendkeys bogosity and related crap. So maybe v1 doesn't get on a server, but it demonstrates that a computer can do task X, which means task X is monkeywork and therefore should be done by said computer. The implementation is dreck, but that can be changed.

    By me, yes. Thanks so very much.

    Sometimes I wish I were that other sort of contractor. I don't suppose the pay's any better, but at least the result would be satisfying.

    Nope, this is something for Mike to do. Call it a growth experience.

  • Hmm (unregistered)
    had a pretty involved setup. Lord only knows what dickery had to happen to get the script fully configured and working; it would need PerlMagick, a dozen or so Perl modules, Wine, xdotool, a VNC server, lots of config tweaking, the works. And Dick wasn't the kind of guy that would be able to piece it all together.

    Hmm, not put that on a production server? Untested even? What was Dick thinking?

  • Erik (unregistered) in reply to Addison

    His intentions may have been good, however my experience is, if you want to change a process your replacement must work well, and it needs to be politically sanctioned at least by your boss.

    Now, if the Perl hack crashes (which isn't entirely unlikely it will sooner or later) the risk is everybody will say "automatic processes sucks, yay for doing it all by hand!" And even more so the next time someone tries to automate the process.

    I wish humans were more inclined to reusing solutions that works (Bugzilla for instance), but I guess it's the need to feel like a genius that makes us try to invent the wheel over and over.

  • BeenThereDoneThatFailed (unregistered) in reply to morry

    This fails several steps short the normal process runs like: propose analyze approve design create advertise sell ship support recycle

  • Wizard Stan (unregistered)

    If I may, I'd like to point out one thing that all the "this is an ugly hack that would be disaster in production" people:

    Logging into a neglected dev server, he got an invalid password error.
    The emphasis being that he was trying to install it to a presumably unused dev box, where no real harm would come. Don't get me wrong, it's still an ugly hack, but how can you make it not-a-hack if you can't even get your proof of concept on a dev server to test it? What is the purpose of a dev server if not for development and experimentation?

Leave a comment on “Fighting the Current”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article