• (nodebb)

    I'd bet a few dollars that Initech is Oracle.

  • (nodebb)

    I've met people like Gary before. Had one guy literally leave a meeting talking about how to improve our design processes and reduce bugs (single, very small team with a boss who had no idea what Agile development was) crying out "This is wasting my time, I have real work to do". I was fired a few months later after the other two smart people on our team jumped ship and I was about to, but was told I could help rebuild the team and be made the manager. The reason? My development skills weren't that great.

  • my name is missing (unregistered)

    I worked in a company where our main application was written by one of the company founders, and it leaked like a sieve because it referenced a C++ framework (in Java app) that required being informed when memory was no longer needed; the founder had ignored that requirement. The programming team supporting the code knew this, but no one was allowed to fix it lest the founder be embarrassed.

  • Robin (unregistered)

    Nice story, but the premise doesn't make sense.

    Not the bit about the code still using 2000-era JS, which although horrible is perfectly believable. But such JS will still run in modern browsers (that's the whole point of JS backwards compatibility - otherwise all those sites that haven't been updated in 20 years but are still on the web wouldn't work at all) - which surely includes those that the devs are using. So the devs still would see stack traces of exceptions, and be able to use the browser's own JS debugger.

    Unless of course Initech forced every developer to use machines which are so old they can't even run any browser version made in the last 10+ years - which even on TDWTF seems rather hard to believe.

  • Labasta (unregistered)

    Stuff like this goes on all the time.

    We have found a situation which indicates there is a problem with input data such that the supplier needs to be alerted to it. It requires that some guy runs a manual tool, then passes the output to someone else whose job is to check the output, then write a report on the results of that output, then report back to a third person, who then writes a standard-form email to the supplier whose input is non-compliant.

    "Why don't we just put a check on the input data in the first place?" pipes up the new guy. "Can't be rocket science to write a quick routine."

    "Argh no," blared the senior member of the team, "that means more code to debug, we're not doing that."

    The real reason we don't do this is because of featherbedding, of course.

  • (author) in reply to Robin

    So, the submitter was a bit light on details here, but my suspicion is that the target runtime wasn't a true JavaScript runtime, but an orphan dialect like JScript or ActionScript. The kind of thing that'd it take time and money to port into real JavaScript, but syntactically is basically JavaScript.

  • DigitalBits (unregistered) in reply to Robin

    The way I read it, because catching and rethrowing a new exception will destroy the original stack trace (even with modern JS engines), and they were constantly doing this, there was no trace of the original stack trace by the time the error was surfaced. I assume the "hacky" code that wrapped all the functions kept the stack trace even over catch-throw.

  • Sauron (unregistered)

    How to get rid of employees to cut costs without having to pay for severance? Easy: make them debug the worst JavaScript code you can find, until they all leave. Initrode-Initech merger... COMPLETE!

  • (nodebb)

    Gary must have felt real good about himself, after the bug was found by somebody else to fix it as if the finding the bug part was a waste of time.

    I don't advocate violence but some faces do cry for a fist.

  • holy shit now I'm actually commenting here... (unregistered) in reply to DigitalBits

    The browser would at least have been able to break as soon as one is thrown AND show the stack at that moment.

  • (nodebb)

    I think I would have struggled pretty hard to not punch Gary in the face in response to his "do you have more ways to waste our time?" comment. What a jerk...

  • (nodebb) in reply to Remy Porter

    Nice story, but the premise doesn't make sense

    Having had a submission of mine turned into a Feature Article. I can confirm that they can take quite some liberties with the story. That article bears only a fleeting resemblance to the actual story. For example, the system that broke in the story was, in reality, the only system that didn't break.

    The submitter was a bit light on details here, but my suspicion is that...

    And this is why. When we submit, we have all the context in our heads. But they're seeing it for the first time. Because humans are bad a communication, we leave out important details and they have to read between the lines quite a bit. Plus, they have to make it an interesting read.

  • Aitkiar (unregistered) in reply to Remy Porter

    If i have to bet, the old javascript is non other than my old pal Internet Explorer. Up to this day, i have to mantain webs that must be IE complaiant because a random deptarment doesn't have the budget to update.

  • Duke of New York (unregistered) in reply to Robin

    Where did you see anything about the code running in browsers?

    Regardless, Allan comes across in the story as having a major savior complex, so much that he saw fit to sabotage the code for the sake of his demo. Gary accused him of wasting the team's time because... well, hadn't he? Was there really no legitimate bug that he could have used instead?

  • (nodebb) in reply to Aitkiar

    In a perfect world, you'd find a way to bill IE-compatibility to the dinosaurs who can't/won't upgrade.

    Alas, in our world, there's usually something in the way.

Leave a comment on “The Debugging Tool”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article