• HVS (unregistered)

    If this guy was such a bobby-badass at programming, why would he go to a big bank to work as a faceless programmer? And didn't he notice any of this in the interview?

  • (cs) in reply to Tim
    Tim:
    Don't knock printf. It does the job, is extremely simple, and doesn't alter the running of the program (e.g. timing, window focus, etc.)
    const char *str = 0; printf(str);
  • (cs) in reply to jay

    No local development environment? = 1 hand tied behind his back Not allowed to use the debugger on the shared development system? = another hand tied behind his back Not allowed to use "trace" statements? = 1 foot tied behind his back

    The real WTF here is that they expected him to develop software with 2 hands and a leg tied behind his back. When you are trying debug code, you need to be able to use the right tool for the job.

    How do you think it would go over if they hired a contractor to build something, but said no hammers or screwdrivers because "they are dangerous"?

    If I have learned anything on this site, it is try to find as much out about the development environment as possible before taking a job. It seems quite a few of the WTFs around here are just this.

  • (cs) in reply to Zapp Brannigan
    Zapp Brannigan:
    Someone:
    How, exactly, does displaying debug messages on a *development* server, not a production one, break security? No one will see the debug messages but the developers, and if your developers are a security risk you're screwed already.
    It would be easy to miss some of debug code before promoting to the production server. I think there was an example of something like that on this site a few days ago.
    And that is why you have things like log4j where you can specify the level of messages that get displayed for dev seperate from production. I.E. statements like: LOGGER.debug(data);

    Do not get shown when you set the debug level from DEBUG to ERROR.

  • Creative Writing Major (unregistered)

    Dear Mark,

    Please stop using paragraph length TDWTF™ submissions as an excercise in creative writing. They are not a personal challenge, and do not require garrulous mending. The extraneous information you seem to crave adds naught but an increased word count to the story; and clouds the already razor thin margin of interest.

    [Submitter] lived the high life during the boom. After the bust, [s]he went to work for a bank. They made funny reports there, and had even funnier rules, intended (efficacy not evaluated: inconsequential to submission) to prevent MONEY LOSS, CONFIDENCE PROBLEMS and BANK RUNS. [Submitter] had a hard time adapting, and so left, confused and irritated, without completing [his/her] assignment. Fin.
    decet: the specialized form of deceit practiced by at least one TDWTF™ editor in a vendetta against pithiness. Full of Fail.
  • luptatum (unregistered)

    There is no debugger, only a spoon.

  • Franz Kafka (unregistered) in reply to Zapp Brannigan
    Zapp Brannigan:
    Someone:
    How, exactly, does displaying debug messages on a *development* server, not a production one, break security? No one will see the debug messages but the developers, and if your developers are a security risk you're screwed already.
    It would be easy to miss some of debug code before promoting to the production server. I think there was an example of something like that on this site a few days ago.

    Not if you don't check it in, although I can't see what the big deal is - just don't put PII in the trace logs.

  • (cs)

    Mark Bowytz reminded himself that he was still a newbie and couldn't be expected to understand the subtle, yet deadly differences between "to", "too", and "two".

  • Dr. Venkman (unregistered) in reply to luptatum
    luptatum:
    There is no debugger, only Zule!

    FTFY

  • Max (unregistered)

    Yeah, there is a level of WTFness here.

    But -- this is also a corporation who has consciously chosen security over efficiency. Banks are like that. And from their perspective, someone trying to throw out business goals (like security) just to do their own job faster or better is, yes, a maverick.

    The correct answer would have been to find a middle ground. Talking to the auditors, asking if policies can be updated to use better technical solutions, etc.

    And frankly, if this guy didn't know that, than he was just as bad of a consultant as the rest of them.

    Are their methods wrong? Yes. So improve them, dude -- don't just scoff at the place and run away.

  • (cs) in reply to Zapp Brannigan

    There are processes to account for removal of debug code other than preventing its use in the first place. Formal code reviews are probably the easiest. I would hope that a bank, which has to meet numerous government and industry regulations, would not let a report be sent to production only on the word of its developer. An V&V group independent of the developers could/should provide confirmation the report is accurate, secure, meets company guidelines, and is free of debug code prior to promotion to the production server.

  • (cs)

    You know what's annoying?

    When someone tells half a story, then leaves everyone hanging with lots of questions. It's like telling the set up for a joke and then WALkING AWAY.

  • dhasenan (unregistered) in reply to David Emery
    David Emery:
    Personally, any time I had to invoke a debugger on my code, I took that as a personal failure, that I didn't now what my code was doing. But then, I'm used to working with languages that support substantial compile-time and even runtime checking.

    When you're dealing with as little as 50KLOC and you aren't the only developer, you might need to rethink that on occasion. An exception stacktrace, if you're lucky enough to have it, won't show you any information about function parameters, but the debugger will.

    Not all code that throws is yours, after all. Not all input is the planned, sanitized input.

  • (cs) in reply to David Emery
    David Emery:
    There are a lot of techniques that build on actually looking at and understanding the code, rather than writing main() {}; and then invoking a debugger. The most extreme of these is Cleanroom (http://en.wikipedia.org/wiki/Cleanroom_Software_Engineering).

    Personally, any time I had to invoke a debugger on my code, I took that as a personal failure, that I didn't now what my code was doing. But then, I'm used to working with languages that support substantial compile-time and even runtime checking.

    You're like a mechanic who knows the whole Haines' manual back to front and knows exactly which parts bolt together to make an engine - but you've never had the top off one and turned the crank by hand to watch how all the parts work and interplay.
  • Duke of New York (unregistered) in reply to David Emery
    David Emery:
    There are a lot of techniques that build on actually looking at and understanding the code, rather than writing main() {}; and then invoking a debugger. The most extreme of these is Cleanroom (http://en.wikipedia.org/wiki/Cleanroom_Software_Engineering).
    Good luck with that when you don't know the data that triggered the fault.

    Really, anyone who tries to apply CSE outside of the big-iron, big-company utility computing environment where it was created is just asking for trouble. There are reasons that IBM doesn't use it anymore.

  • Dan (unregistered) in reply to NerfTW
    NerfTW:
    You know what's annoying?

    When someone tells half a story, then leaves everyone hanging with lots of questions. It's like telling the set up for a joke and then WALkING AWAY.

    You know what's REALLY annoying?

  • Peter (unregistered) in reply to An embedded developer

    That's why the hardware designer (me) added those extra LEDs and test points! My debugging involves scope probes and test points...

  • RuKidding (unregistered) in reply to Creative Writing Major
    Creative Writing Major:
    Dear Mark,

    Please stop using paragraph length TDWTF™ submissions as an excercise in creative writing. They are not a personal challenge, and do not require garrulous mending. The extraneous information you seem to crave adds naught but an increased word count to the story; and clouds the already razor thin margin of interest. snip

    Dear Creative Writing Major,

    Some of us enjoy the story and prefer the author retain the extraneous information you seem so abhorrent to. If you are so busy that the increased length causes problems for you, perhaps you shouldn't have read the article or taken the time to post a comment until after your other obligations were satisfied.

    I found your rant an interruption to what has thus far been a very amusing chain of comments. Please stop discouraging TDWTF™ contributors. I appreciate what they do.

    Good day sir.

  • Schnapple (unregistered) in reply to Ken B
    Ken B:
    "Debug? We don't need to debug. We get it right the first time!"

    The sad thing is I've had a boss who made a similar statement: "Debugging is for people with too much time on their hands"

  • Ken B (unregistered) in reply to Tephlon
    Tephlon:
    mrprogguy:
    Mitur Binesderti:
    *SNIP* Pokipsy *SNIP*
    *SNIP* And don't use place names you can't spell. What's doubly-WTFy is that you could actually have looked it up since you're on the World Wide Web when you respond!

    See, there's this new thing called Google. And this other thing called Wikipedia. You should try them.

    heh... Have you tried finding Poughkeepsie in Google or Wikipedia when all you know is that it sounds like "Pokipsy"?
    Try using Google for "definition of pokipsy", and the first link says:

    Poughkeepsie is a city in New York, U.S.A. and serves as the county seat of Dutchess County, located...
  • noob (unregistered)

    Is there a single story on this website where the script doesn't go:

    1. person is smart...honest...it's not them that's the problem
    2. person joins company that (surprise!) does something stupid
    3. person quits (either in disgust or with a wry smile on their face)

    I work at a company that does a lot of dumb things. I imagine most of you do too. However, I take pride in my work and think that some minor dumb things are worth forgiving for the greater good.

    For example, I don't have access to a debugger...I rely on black box testing wherever I can and when I get stuck I recompile for a different platform that I can debug the code on. It sucks, but it's a challenge...so I deal with it.

    This really doesn't seem like a WTF to me.

  • Ken B (unregistered) in reply to Schnapple
    Schnapple:
    Ken B:
    "Debug? We don't need to debug. We get it right the first time!"
    The sad thing is I've had a boss who made a similar statement: "Debugging is for people with too much time on their hands"
    "If you don't have time to do it right the first time, what makes you think you have time to do it again?"
  • Think before you write (unregistered)

    While forbidding the use of a debugger is of course rubbish, I do have to say, I see a lot of developers who are too careless or lazy writing the code in the first place and then spend a lot of time debugging it.

    Thinking carefully and paying attention to detail when writing code greatly reduces your need for a debugger - and guess what, even though you're slower writing the code, the time saved by fixing fewer bugs more than makes up for it!

  • Think before you write (unregistered) in reply to Code Dependent

    No, as opposed to careless people who don't pay enough attention to detail when writing code. A lot of people don't understand that if they spend more time writing the code, rather than rushing, they'll be faster overall!

    +1 for David Emery's stance.

  • Dunkirk (unregistered)

    The key word is buried in the article: "auditors." They were the bane of my existence during my 14.5 years at a Fortune 250 company. See, the upper management doesn't know anything about "IT" (and isn't expected to), so they rely on middle management, who know NOTHING about "IT," so they hire auditors who know F**K ALL about "IT," and are paid exhorbitantly for the privilege of being so ignorant. The person they put in charge of internal audit where I was just literally scoured the internet, cut-and-pasted from any and all "best practices" articles he could, and came up with our IT policies. When I pointed out that this left us with 7 different recommendations for things like username style and password complexity... Well, let's just say that it ground down to him screaming down the line to me. I've left such madness and hired on with a startup while the company I left is teetering in "this economy" precisely because the continue to know nothing about "IT" and how it might help them in their field. The few people who recognize how to use these newfangled "computers" to gain a competitive advantage are marginalized just like this guy was for being a "maverick," while IT budgets get slashed to the bone year after year after year. Companies like this get what they deserve: A BIG FAT STIMULOUS CHECK! ... PROFIT!

  • Fudge (unregistered) in reply to DaarkWing
    DaarkWing:
    I would hope that a bank, which has to meet numerous government and industry regulations, would not let a report be sent to production only on the word of its developer.

    Bahahahah. Hah. cough

    Take it from a dev at one of their major competitors.

  • Joe (unregistered) in reply to Stig
    Stig:
    "Next thing you'll be wanting a compiler instead of hand-compiling your code like the rest of us"

    Hand-compiling code? CODE? You need a quasi-english language to spell out your program? Do you point out the words with your finger when you read?

    Write it in native binary like a man, chuck.

    Are you kidding, Stig? Programming like a man means you use a sharpened (with your teeth) magentized paperclip to toggle the bits into the hard drive platters, like God intended.

    --Joe

  • OldTechSupport (unregistered) in reply to Dennis
    Dennis:
    > the last thing we'd want is an end user gleaming sensitive system information from a debug message!

    Ah, gleaming white and shiny new! The best kind of sensitive information!

    BTW, it should be "gleaning".

    Thank you, saved me the trouble.

    (I learned the word "gleaning" from my second grade teacher, who used it in a report card comment.)

  • Adam (unregistered) in reply to Tim
    Tim:
    Don't knock printf. It does the job, is extremely simple, and doesn't alter the running of the program (e.g. timing, window focus, etc.)

    From 6 days ago on this very site:

    Oren Ben-Kiki:
    His code was used in a factory production environment to control, amongst other things, the temperature of vats doing some tricky chemical reactions. The relevant part of the code was a basic negative feedback loop. Test the temperature, apply correction, lather, rinse, repeat.

    Naturally, in an environment like this, you never release code to production without testing it up the wazoo. To help the testing they had a print statement inside that loop, so they could see what was going on in real-time.

    Well, they tested it an all was well. Then they took out the print statement, recompiled, and deployed it to the production. No tedious re-testing - there is no possible way this would affect the behavior of the program, right?

    Well... it turned out there was a bug in the compiler. Now, this was the 80s, and these things happened more often that today's spoiled brats expect. I have personally seen C++ and Fortran compilers failing - as late as 94. To this day I don't 100% trust these tricksy beasts.

    At any rate, the bug reversed the interpretation of the if statement, converting the code to a positive feedback loop. Which, of course, is a very negative thing to have.

    The resulting explosion took off the top of the vat, the roof, and everything in between. Luckily this did not include any people's heads - except in the metaphorical sense :-)

    WHERE IS YOUR PRINTF NOW?!

  • Cujo (unregistered) in reply to Stig

    Do it with punch cards and make sure there's a crack security team to ensure the cards are carried to the card reader and locked up after the object code is created.

  • Little Phillip (unregistered) in reply to Cujo
    Cujo:
    Do it with punch cards and make sure there's a crack security team to ensure the cards are carried to the card reader and locked up after the object code is created.

    Funny this came up, I just got done trading a few notes with my father about his master's thesis, which was programmed using punch cards on The Rice University Computer.

    I was blown away after learning how its memory worked. Simply amazing. Imagine having to time your reads and writes to get at the data you want...

  • (cs) in reply to Joe
    Joe:
    Are you kidding, Stig? Programming like a man means you use a sharpened (with your teeth) magentized paperclip to toggle the bits into the hard drive platters, like God intended.

    --Joe

    You reminded me of this:

    [image]
  • Procedural (unregistered) in reply to Tim
    Tim:
    Don't knock printf. It does the job, is extremely simple, and doesn't alter the running of the program (e.g. timing, window focus, etc.)

    Sure it does. See how all of your text reaches output in neat little lines, rather than a jumble ? Somewhere in there is a semaphore, and somewhere out there is a developer who doesn't know that he is serializing his tasks and therefore not adequately preparing for a slew of thread contention situations.

  • Duke of New York (unregistered)

    real programmers take jokes that weren't that funny to begin with and run them into the ground.

  • Procedural (unregistered) in reply to noob
    noob:
    Is there a single story on this website where the script doesn't go: 1) person is smart...honest...it's not them that's the problem 2) person joins company that (surprise!) does something stupid 3) person quits (either in disgust or with a wry smile on their face)

    I work at a company that does a lot of dumb things. I imagine most of you do too. However, I take pride in my work and think that some minor dumb things are worth forgiving for the greater good.

    For example, I don't have access to a debugger...I rely on black box testing wherever I can and when I get stuck I recompile for a different platform that I can debug the code on. It sucks, but it's a challenge...so I deal with it.

    This really doesn't seem like a WTF to me.

    No really, it is. Their only defense against stray trace statements appearing in the stagnant waters of production code appears to be to have a manager asking not to put trace statements in. A better solution would be:

    1. Create an isolated testing subnet for developers, and only let those with installation and recovery chores get access to the main network; why do they need live access to production systems any way, especially in a bank ? Their system might not allow you to run Wireshark but that shadow pass-through router in the micro-ITX box under the desks does.

    2. Have someone write a lint checker for production code and have it part of any installation that the checker be run. As this is .net code, writing this is trivial: see if compiled code resolves a pointer stub to the debugging functions, and then either slap ther virtual wrists of the developers reminding them of release code policy or restub the function to something that has no side effect.

  • LewisC (unregistered)

    I bet Chuck Norris could remote debug even though it was disabled.

    LewisC

  • Peter (unregistered) in reply to Stig

    "Write it in native binary like a man, chuck."

    Pay you need TWO states for your code. Both ones AND zeroes?! We don't like bloat round here!

  • (cs)

    In one of my early jobs we had a "Glossary for Programmers" that included the following definition:

    Debugger: Dee person who wrote da program in da first place

  • (cs) in reply to Think before you write
    Think before you write:
    While forbidding the use of a debugger is of course rubbish, I do have to say, I see a lot of developers who are too careless or lazy writing the code in the first place and then spend a lot of time debugging it.

    Thinking carefully and paying attention to detail when writing code greatly reduces your need for a debugger - and guess what, even though you're slower writing the code, the time saved by fixing fewer bugs more than makes up for it!

    If you forced those same programmers to "think carefully and pay attention" it would just take them twice as long to come up with the same stupid WTFs they already created. Programming is hard.

    How many WTFs on this site could have been solved by someone saying "There has to be a better way" and spending some time surfing google or reading manuals?

  • Chainsman (unregistered)

    This could be the most idiotic tdwtf story ever.

  • David Emery (unregistered) in reply to dhasenan

    Most of my work has been done on large command & control or ATC systems > 1M SLOC.

    Good/complete interface specifications are essential to success on large projects. Failing to specify completely is a key part of a good design/code review, particularly with respect to error/exception handling, including parameter/input checking and invariants. Failure to -implement- that specification subjects one to peer pressure/abuse and if it continues is cause for getting rid of that person.

    Debuggers are often essential tools for complex interactions. But in my view they should be a tool of -last resort-, rather than standard practice.

  • Konrad (unregistered) in reply to Tim
    Tim:
    Don't knock printf. It does the job, is extremely simple, and doesn't alter the running of the program (e.g. timing, window focus, etc.)

    Are you kidding. a single printf inside a loop can throw notions of timing out the window. I can't think of how many times I've found a race condition after removing print statements.

  • EmperorOfCanada (unregistered)

    Debug? I just keep an AM radio tuned into the CPU frequency and listen to the data flow through the registers.

  • fdizzle (unregistered)

    TRWTF is that Peter quit in less than a week during an economic crisis because he couldn't live with his employer's coding conventions.

    If the bank doesn't want you to code trace statements in because there's a risk you'll leave them in, DON'T. Hell, I myself have come close to leaving my traces in until production, and when you're working on a large quantity of work, it is much more likely that you'll slip up.

    As for the debugger, what's the problem? Debug it manually like a real man, are you completely useless?

  • (cs) in reply to LewisC
    LewisC:
    I bet Chuck Norris could remote debug even though it was disabled.
    Actually, Chuck Norris doesn't know how to use the debugger, because he never came across a situation requiring it; his code is bug-free.
  • Porklovsky (unregistered)

    Debug? Hardcore developers upload flawless code directly into production servers. There are no bugs, just users that can't understand that what they want is WRONG.

  • Adrian Pavone (unregistered) in reply to Stig
    Stig:
    "Next thing you'll be wanting a compiler instead of hand-compiling your code like the rest of us"

    Hand-compiling code? CODE? You need a quasi-english language to spell out your program? Do you point out the words with your finger when you read?

    Write it in native binary like a man, chuck.

    We used to DREAM of writing it in native binary. In my day, we had a base-1 system where the only way to input details was to hold down a single button for some length of time. We had to hold down the button for 25 hours a day just to get a single piece of input! Then, when we left to go home for the day, security would flog us and cut us up into little pieces. But you try telling that to the young developers of today and they won't believe you.

  • csrster (unregistered) in reply to HVS
    HVS:
    If this guy was such a bobby-badass at programming, why would he go to a big bank to work as a faceless programmer? And didn't he notice any of this in the interview?

    We have an ex-consultant working in our department. He switched track because he got tired of living most of his life in anonymous hotel rooms and working 80 hours a week.

  • Grammar Nazi (unregistered)

    The word is "gleaning," not "gleaming".

    http://www.thefreedictionary.com/glean

    But I do empathize. If it's not security, it's turf, or something else. There's always an excuse to keep the really good coders from making everybody else look bad.

  • (cs) in reply to icelava
    icelava:
    LewisC:
    I bet Chuck Norris could remote debug even though it was disabled.
    Actually, Chuck Norris doesn't know how to use the debugger, because he never came across a situation requiring it; his code is bug-free.
    You're getting mixed up with Bruce Schneier (not a good move). Chuck Norris just glances at the code and it debugs and performance-optimizes itself.

    (BTW, there are ways to produce correct code first time. They're expensive so they tend to only be used in critical systems like fly-by-wire and railway signalling...)

Leave a comment on “Debugging is Risky”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article