• Martin (unregistered)

    Who needs debugger? We, experienced PHP developers, use "echo" statements all the time. Put it here and there and all problems are solved!

  • (cs)

    Yup, another WTF perpetuated by a developer with a lack of testicular fortitude, well done!

  • The Dread Pedant Roberts (unregistered)

    After nearly two years, I've concluded that you refuse to proofread articles on purpose ;) - it's your own inimitable trollery against your readers. Like a text-based MFD.

  • Zog (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.

    PAH...I type code by wiping my feel on the carpet and tapping the serial port with my finger and using the static electricity I've generated...

    Anyway, I think I've worked at that place...I should did out some of my old Lotus Notes (v3 !!!) stuff to find a glut of WTFs??!?!!

  • 50% Opacity (unregistered) in reply to Code Dependent
    Code Dependent:
    So the opposite of debug is... bug!

    No, it's obviously "enbug", which is a synonym of "programming".

  • iMalc (unregistered)

    Debugging using Trace statements!?!?! Talk about living in the dark ages!

    Amazing how many people haven't heard of "When Hit" breakpoints!

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

    Well in ASP printf is pretty useless.

  • Henrik Rune jakobsen (unregistered)

    If I had not worked at a bank before I would have thought this story was made up. Now it just brings back bad memories... brrrrr...

  • Orbstart (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.

    That being said, having a firewalled test and integration environment is certainly a best practice. So to me this is a combination of a "WTF" with respect to the corporate policies, and frankly in my mind a "WTF" with respect to how one develops software. Score me strongly on the side of getting it right before executing the code (and that often means a lot of compile cycles until the compiler and static checking tools & I together agree the code is correct.)

    Have you finished that Hello World program yet or do you need another six months?

  • Disgruntled Postal Worker (unregistered) in reply to Someone
    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.

    As as developer at a bank subject to strict banking secrecy laws, I can explain this.

    "if your developers are a security risk you're screwed already"

    This sort of fatalism is not acceptable to the customers and share holders of a financial institution.

    Code promoted from DEV to TEST must be identical and reproducible. There is no removing debug statements before deploying to TEST and no recompiling with different settings. Any trace statements that would end up in the logs in the DEV environment would go all the way to production, and anyone with read access to the file system (tech support for example) would be able to read private customer information in the log files .

    The developers are not allowed to modify or even touch the code past the DEV stage, for security reasons. This is to prevent 'hidden' code ending up in production that can not be traced back to the author in the standard DEV repository. You don't want a contractor to be able to sneak code into production that would add a couple of digits to a certain account, or forward the details of a certain account to someone else.

    People who do have access to the Test, Quality Assurance and Production stages are never allowed to modify the package in any way. People who are allowed (and have the tools and access) to modify a package are never allowed access to anything past the DEV stage.

    The same applies with regard to remote debugging. If this were enabled, it would be potentially be possible to make untraceable changes to the running code, or just to read private and sensitive customer data.

    You would think that the bank in the article could save a lot of time and money by installing a local dev server on the development machines of the programmers. I don't know what their reasons are to disallow this, but chances are either the insurance, local laws or the share holders require it.

  • Georgem (unregistered)

    Comment? We're a bank! The last thing we want is an end user reading a comment!

  • noob (unregistered) in reply to Procedural
    Procedural:
    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.

    I see your point. To correct and clarify how I feel: not having a debugger is not a WTF. Not having any test environment whatsoever is.

  • Georgem (unregistered) in reply to noob
    noob:
    Procedural:
    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.

    I see your point. To correct and clarify how I feel: not having a debugger is not a WTF. Not having any test environment whatsoever is.

    I agree. I can't remember the last time I needed a debugger. Logging and unit tests do it better, IMHO. And, yes, I am aware of how debuggers work and what they can do.

    The real WTF here is that dev managers and what-not couldn't tell the difference between a dev and production environment. As for the "challenge" of having to compile for another platform in order to debug, the WTF there is that the company isn't asking "how can we make tedious, non-business tasks easier or non-existent for devs, so we can maximise production, ergo, teh moneyz?"

  • j (unregistered) in reply to jay

    You had ones? Lucky bastard, we only had zeros!

  • anonymous (unregistered) in reply to Stig

    TYPING in binary? Use a magnetised needle on an open hard drive like the rest of us!!!

  • Crashthatch (unregistered) in reply to Stig

    Binary? Cushy.

    Real men use a magetised needle and a steady hand.

  • Sane Person (unregistered) in reply to Bappi
    Bappi:
    jay:
    Would you like the maid to bring you a cup of tea, sir?
    That sounds rather nice, actually. Is she Irish?

    I thought Irish girls mostly brought beer. Or my book. http://thedailywtf.com/tizes/ads/1/wth-ad.jpg (Gratuitous commercial plug.)

  • Dunkirk (unregistered) in reply to Disgruntled Postal Worker
    Disgruntled Postal Worker:

    The developers are not allowed to modify or even touch the code past the DEV stage, for security reasons. This is to prevent 'hidden' code ending up in production that can not be traced back to the author in the standard DEV repository. You don't want a contractor to be able to sneak code into production that would add a couple of digits to a certain account, or forward the details of a certain account to someone else.

    People who do have access to the Test, Quality Assurance and Production stages are never allowed to modify the package in any way. People who are allowed (and have the tools and access) to modify a package are never allowed access to anything past the DEV stage.

    That's a great idea, and -- IF IT WERE ACTUALLY IMPLEMENTED -- would satisfy the whole point of control systems. In my company, though, it was just POLICY, and there were no actual systems in place to PREVENT this. Doing so would become a big hassle, and cost a lot of money, and, well, THAT ain't gonna fly. But unless you technologically prevent this sort of thing, at best you have but a Good Idea (TM). (As an example, it was written policy that it was "security's" job to handle user accounts, but people who had root or administrator on the machines weren't prevented from doing anything they wanted with the accounts anyway.)

    What I'm trying to say is that, if your business is "cool" enough to actually, really, truly NEED this kind of control, then, great, put it in your policies, put the systems in place to do it (like mandatory access controls, which is Hard), and do auditing against it.

    What I actually have found in real life is that Big Corp goes out and hires Big Auditing Firm who come in with "Best Practices" for everyone BUT the people they're supposed to be helping, and corporate IT policies then come to reflect controls designed for people with MUCH higher and stricter standards than they need. So you get policies but no systems -- rules with no teeth -- and a lot of wasted effort getting around them because if you didn't do so, you'd never get anything done on time.

    Meanwhile, everyone gives lip service to the Right Way of doing things, the auditors are pacified, and the end result is that the sort of thing financial controls are supposed to prevent are WIDE OPEN, while upper management thinks that all the i's are crossed and the t's dotted.

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

    Real men read threads before posting and make up jokes that haven't been heard before.

  • lolwut? (unregistered) in reply to RuKidding
    RuKidding:
    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.

    I suspect you missed the point. I don't think CWM was trying to discourage contributors. I read his overly cutesy comment letter as actually encouraging TDWTF editors to stop fabricating story structures around submissions, and let the contributions through on their own merit, or at most, minimally anonymized. If you actually read the article, the difference between Mark's voice and the voice of the contributor is painfully obvious, because Mark doesn't seem able to weave the WTFacts into his yarn without hot glue, duct tape and baling twine. This isn't about the author, it's about the editor. Reading comprehension goes best with a helping of common sense.

    Cheers,

    lw

  • Bork (unregistered) in reply to lolwut?
    lolwut?:
    RuKidding:
    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.

    I suspect you missed the point. I don't think CWM was trying to discourage contributors. I read his overly cutesy comment letter as actually encouraging TDWTF editors to stop fabricating story structures around submissions, and let the contributions through on their own merit, or at most, minimally anonymized. If you actually read the article, the difference between Mark's voice and the voice of the contributor is painfully obvious, because Mark doesn't seem able to weave the WTFacts into his yarn without hot glue, duct tape and baling twine. This isn't about the author, it's about the editor. Reading comprehension goes best with a helping of common sense.

    Cheers,

    lw

    Hmmm, after reading lolwut?'s comment, methinks RuKidding seems a little too offended.

    And what's this? This confusing subject/object placement in connection with the adjective "abhorrent"...? Does he really think the extraneous facts abhor Creative Writing Major? No, that can't be it...

    Hold a tick, I recognize this style of literary abuse! And, of course! ...facepalm... How did I not see it before: Confusing the "author" "retain[ing]" extraneous information, but admitting to increased length? MARK, is that YOU!?

    How shameful, it seems you let Creative Writing Major get under your skin enough to flame your own boards anonymously and accidentally admit that the stories are fabricated -- er.. "author"ed -- by the editors.

    My, how embarrassing. :$

  • Oh god how did this get in here I am not good with computer (unregistered)

    Please god, no more lolcats on here. I am beginning to think that there is no safe haven from seeing that retarded #$%!. Seriously they are as mind-numbingly dumb as the ads one see for "L@@k!!!! OVAR ONE THOUSAND SMILIES FOR FREE!!!111ONE-THOUSAND ONE-HUNDRED ELEVEN!!!!" They have been posted here before but I plead you to have some dignity and dont post them here ever again. This is your blog but seriosly show some respect for yourself. You showed feel as ashamed for posting it as you would be if you ever installed BonziBuddy.

  • (cs) in reply to Tephlon
    Tephlon:
    heh... Have you tried finding Poughkeepsie in Google or Wikipedia when all you know is that it sounds like "Pokipsy"?

    Out of curiosity I just tried this. I put Pokipsy into wikipedia's search... it took me directly to the article on Poughkeepsie, New York.

    I guess the original assertion, which did specifically mention wikipedia, for good or ill, is correct.

  • Disgruntled Postal Worker (unregistered) in reply to Dunkirk
    Dunkirk:
    Disgruntled Postal Worker:

    The developers are not allowed to modify or even touch the code past the DEV stage, for security reasons. This is to prevent 'hidden' code ending up in production that can not be traced back to the author in the standard DEV repository. You don't want a contractor to be able to sneak code into production that would add a couple of digits to a certain account, or forward the details of a certain account to someone else.

    People who do have access to the Test, Quality Assurance and Production stages are never allowed to modify the package in any way. People who are allowed (and have the tools and access) to modify a package are never allowed access to anything past the DEV stage.

    That's a great idea, and -- IF IT WERE ACTUALLY IMPLEMENTED -- would satisfy the whole point of control systems. In my company, though, it was just POLICY, and there were no actual systems in place to PREVENT this. Doing so would become a big hassle, and cost a lot of money, and, well, THAT ain't gonna fly. But unless you technologically prevent this sort of thing, at best you have but a Good Idea (TM). (As an example, it was written policy that it was "security's" job to handle user accounts, but people who had root or administrator on the machines weren't prevented from doing anything they wanted with the accounts anyway.)

    What I'm trying to say is that, if your business is "cool" enough to actually, really, truly NEED this kind of control, then, great, put it in your policies, put the systems in place to do it (like mandatory access controls, which is Hard), and do auditing against it.

    What I actually have found in real life is that Big Corp goes out and hires Big Auditing Firm who come in with "Best Practices" for everyone BUT the people they're supposed to be helping, and corporate IT policies then come to reflect controls designed for people with MUCH higher and stricter standards than they need. So you get policies but no systems -- rules with no teeth -- and a lot of wasted effort getting around them because if you didn't do so, you'd never get anything done on time.

    Meanwhile, everyone gives lip service to the Right Way of doing things, the auditors are pacified, and the end result is that the sort of thing financial controls are supposed to prevent are WIDE OPEN, while upper management thinks that all the i's are crossed and the t's dotted.

    At the banks I've worked for, it goes a lot further than just lip service. The laws of various countries (e.g. Luxembourg, Switzerland) require a high degree of confidentiality. The development team couldn't even get a copy of the log files in case of a bug. You would get manually audited fragments.

    I can't think of a reason why a customer would ever need that level of privacy other than for tax evasion, but that's another matter

  • Duke of New York (unregistered) in reply to Oh god how did this get in here I am not good with computer
    Oh god how did this get in here I am not good with computer:
    !!!111ONE-THOUSAND ONE-HUNDRED ELEVEN!!!!
    this isn't any funnier than the lolcats
  • Wanker (unregistered) in reply to Oh god how did this get in here I am not good with computer
    Oh god how did this get in here I am not good with computer:
    Please god, no more lolcats on here. I am beginning to think that there is no safe haven from seeing that retarded #$%!. Seriously they are as mind-numbingly dumb as the ads one see for "L@@k!!!! OVAR ONE THOUSAND SMILIES FOR FREE!!!111ONE-THOUSAND ONE-HUNDRED ELEVEN!!!!" They have been posted here before but I plead you to have some dignity and dont post them here ever again. This is your blog but seriosly show some respect for yourself. You showed feel as ashamed for posting it as you would be if you ever installed BonziBuddy.
    I think this guy's TRWTF™
  • Wanker (unregistered) in reply to Bork
    Bork:
    lolwut?:
    RuKidding:
    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.

    I suspect you missed the point. I don't think CWM was trying to discourage contributors. I read his overly cutesy comment letter as actually encouraging TDWTF editors to stop fabricating story structures around submissions, and let the contributions through on their own merit, or at most, minimally anonymized. If you actually read the article, the difference between Mark's voice and the voice of the contributor is painfully obvious, because Mark doesn't seem able to weave the WTFacts into his yarn without hot glue, duct tape and baling twine. This isn't about the author, it's about the editor. Reading comprehension goes best with a helping of common sense.

    Cheers,

    lw

    Hmmm, after reading lolwut?'s comment, methinks RuKidding seems a little too offended.

    And what's this? This confusing subject/object placement in connection with the adjective "abhorrent"...? Does he really think the extraneous facts abhor Creative Writing Major? No, that can't be it...

    Hold a tick, I recognize this style of literary abuse! And, of course! ...facepalm... How did I not see it before: Confusing the "author" "retain[ing]" extraneous information, but admitting to increased length? MARK, is that YOU!?

    How shameful, it seems you let Creative Writing Major get under your skin enough to flame your own boards anonymously and accidentally admit that the stories are fabricated -- er.. "author"ed -- by the editors.

    My, how embarrassing. :$

    Win.

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

    A former boss actually told me that at one point. But I managed to keep a straight face. :)

  • Jeremy Friesner (unregistered) in reply to Zapp Brannigan
    Zapp Brannigan:
    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.

    There are ways to minimize that risk. What I do is start all my debug printf()s in the leftmost column of code, to make it extremely obvious that they are only meant to be there temporarily.

    Finding them before a checkin is a simple matter of 'grep ^printf *.cpp' (or your favorite equivalent). If you wanted to, you could even put in a SVN hook that would reject commits containing any lines with ^printf in them.

    Or if that's not enough, you could just do the easy thing and have a special debug_print function that is a no-op when executed on the production server.

  • Jeremy Friesner (unregistered) in reply to Code Dependent
    Code Dependent:
    ...as opposed to those of us who deliberately write bugs into our code so we'll have something to fix?

    Nah, as opposed to those of us who pound out some code that compiles and looks like it might work, but never go back to carefully review what we've written. Easier to just wait for the QA team to test it for us, no? :^)

  • Bob (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.
    You're so smart! Would you like a cookie and a couple of gold stars?

    The rest of us mere mortals sometimes have whole minutes where we know we made a mistake and need to find it, and having tools to help us find our mistake is something we're ok with.

    A bug is a mistake? It means you did something wrong? And a mistake is "a personal failure"? Well, I guess that's working out for you, so that's cool.

    But I tell you, I'll be on my knees praising the first deity to claim credit for giving me a boss who isn't as much of a hard-ass perfectionist as you are.

  • Bob (unregistered) in reply to Mr B
    Mr B:
    Yup, another WTF perpetuated by a developer with a lack of testicular fortitude, well done!
    Hey, Chuck! It's great to finally meet the man himself, the man with balls so powerful that banks will rearrange their entire business structure just because your mighty and heroic balls walked in the door.

    Your devout belief that one man fighting alone against overwhelming odds can fix all corporate problems merely by the power of balls in an inspiration to all of us weak and helpless cowards.

    In fact, I'ld be prepared to go as far as saying that your entire life is a testament to balls.

  • Stark (unregistered) in reply to Stig

    "Write it in native binary like a man, chuck." That's right! screw hex, yay binary! My keyboard has only two keys... "0" and "1"

  • Adam Jorgensen (unregistered)

    I'm still surprised by how few developers in the working world seem to know that debugging even exists.

  • Joey (unregistered)

    That's pretty daft. It should be pretty easy to set up secure debugging.

    The big WTF here is obvious. Without having a good system for finding problems in code and testing there's an even greater chance of a bug occuring that allows people to violate security.

  • Walker (unregistered) in reply to Stig

    Writing native binary?

    A real man creates software by tapping on the CPU with a pair of drum-sticks, bud.

  • epso (unregistered) in reply to dmitriy
    dmitriy:
    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]

    "Emacs is a nice OS - but it lacks a good text editor."

  • (cs)

    As someone who spent about 5 hours last night alternating between the Visual Studio debugger and WinDbg trying to diagnose a "problem" that turned out to be a consequence of either corrupted debugging symbols or a broken debugger, I'm getting a kick out of this thread.

    (For WinDbg people, this is a couple commands I ran after a line in std::vector::_Insert_n that said "_Ty _Tmp = _Val;". _Ty is a template parameter, in this case std::string. _Val is a parameter, declared as "_Ty const &".)

    0:000> dt -r _Val
    Local var @ 0x12a14c Type std::basic_string<...>*
    0x0012a5fc 
       +0x008 _Bx              : std::basic_string<...>::_Bxty
          +0x000 _Buf             : [16]  "000000"
       +0x018 _Mysize          : 0xf
       +0x01c _Myres           : 0xcccccccc
    
    0:000> dt -r _Tmp
    Local var @ 0x12a0f8 Type std::basic_string<...>
       +0x004 _Bx              : std::basic_string<...>::_Bxty
          +0x000 _Buf             : [16]  "0b00000000"
       +0x014 _Mysize          : 0xa
       +0x018 _Myres           : 0xf

    (I've edited that a little bit. The relevant stuff is still left.)

    Note that it sees _Val as a string * and _Tmp as a string. However, it thinks the offsets of the members are different.

    It says that _Bx (the backing store in MS's string implementation*) is at offset 4 in _Tmp (which is right) but offset 8 in what _Val points to.

    Furthermore, everything is shifted 4 bytes: the first 4 characters of the string are truncated in _Val since it thinks it starts 4 bytes after where it is. It thinks that _Mysize has value 0xf in _Val because it thinks it's at offset 0x18; in actuality, offset 0x18 is _Myres, which you can see has value 0xf in _Tmp. Finally, _Myres in _Val then gets shifted off to memory following that, which in this case is the characteristic 0xCCCCCCCC.

    Note that all this is after copying from _Val (the broken one) to _Tmp (the correct one), so the data is there. (The debugger showed the same stuff before the declaration of _Tmp too, just for the record.)

    Basically wherever I looked around that point, string objects were displayed fine, but string * and string & objects were broken.

    I shouldn't have relied on the debugger being correct for as long as I did, but I haven't seen any issues like this before in unoptimized debug code.

    • This holds either short strings of 16 characters or less directly in the string object or a pointer to memory where the string is stored. In the examples above the pointer is invalid of course (it appears to be in a union with the short string option) so I didn't bother to show it.
  • LizardFoot (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.

    native binary?? We use electrons!

  • meh (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"?

    I do agree that he shouldn't have used a placename he doesn't know.

    http://www.google.com/search?hl=en&safe=off&q=pokipsy+place+name&aq=f&oq=&aqi=

  • T.C (unregistered)

    Heard it all before:

    "Unit testing? We don't do unit testing because it takes to much time".

    (From a project manager) "You developers need to do it once and do it right!"

    When you are unable to do your job because of the stupidity and/or arrogance of your 'superiors' it is time to move on.

  • (cs) in reply to T.C

    And despite many banks having such tight security rules, half the major banks still had SQL injection issues on their login screen for months after SQL injection became a well publicised problem.

  • Geoff (unregistered)

    One of our developers' wives can't see why we don't just write the code properly in the first place. I suppose she has a point, if you wrote it without bugs it would cut out a lot of testing time.

  • GK (unregistered)

    The problem there is naive upper echelons entrusted the wrong person to set and fix development standards. In those situations, you can almost guarantee it's one person making that rule. Generally that person has been around forever, or left a legacy so strong no one re-examined policy.

    Yeah, corporate environments breed that, but there's 80 people in that office that can poke their heads up and say something about it.

  • Unit tests? (unregistered)

    What about writing unit-tests? You shouldn't need a debugger if your code is properly unit-tested.

  • Dan (unregistered) in reply to Stig

    Real programmers use a magnet and a steady hand... http://xkcd.com/378/

  • jez (unregistered) in reply to Stig
    Stig:
    Write it in native binary like a man, chuck.
    - LMFAO

    Remote Debugging: "what's that? Like putting Response-dot-Write statements in and stuff?"

    classic asp.WTF, ROFLMAO, had these guys ever stepped thru lines of code in their lives? I suppose the manager worried code comments could be reflected by "problom people" who download DLLs off the server... debugging is risky:)

  • flip-flops (unregistered) in reply to Captain Oblivious

    No, it was definitely UBS. This coming from someone who will be getting the hell out of there at the earliest opportunity (which, with a 3 month notice period, can't be early enough!) precisely because of bone-headed, futile, bureaucratic measures, similar to the one described in the article, to counter perceived and misunderstood security risks. Bet you the cube farm was the one in Opfikon, too.

  • (cs)

    TRWTF is that he was going to attach a debugger to a program running on a local testing server. Think of all the security issues!

  • BK201 (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.

    http://xkcd.com/378/

Leave a comment on “Debugging is Risky”

Log In or post as a guest

Replying to comment #:

« Return to Article