• (cs)

    // This comment sux. I can't figure out why it's here. // It really really SUCKS and should be used for debugging // only. string obviousIronicPostComment = "done";

  • Sr. Developer (unregistered)

    It was as though someone had gone in and added those comments specifically to scare Michelle off.

    So, Michelle, how many other times in your life have you been within one inch of a clue and still failed to pick it up?

    (Just kidding!)

  • (cs)

    I can see doing this sort of thing. On occasion, I've been forced to do things against my will/better judgement by your garden variety PHB. If you argue (beyond a certain point), you jeopardize your job, so you just sigh, close your eyes, and warn the next person as best you can.

  • (cs)

    The comments are specifically added to see how long it would take for the new guy to freak out. They must be running tabs in office!

  • Jeroen Brattinga (unregistered)

    Maybe that code has been around long enough to become self-aware?

    I guess that's what they mean by self documenting code.

  • Steven G. Aldana, PH.D. (unregistered) in reply to snoofle

    You know what sucks? The attitude of the jerk that commented the code. I assume he had difficulty understanding the code or maybe he was just too good to work on a legacy application. Perhaps he had a permanent case of the Mondays.

  • (cs) in reply to Lars Vargas
    Lars Vargas:
    // This comment sux. I can't figure out why it's here. // It really really SUCKS and should be used for debugging // only. string obviousIronicPostComment = "done";
    Shouldn't that be: string obviousIronicPostComment = "fist!";
  • (cs) in reply to Steven G. Aldana, PH.D.
    Steven G. Aldana:
    You know what sucks? The attitude of the jerk that commented the code. I assume he had difficulty understanding the code or maybe he was just too good to work on a legacy application. Perhaps he had a permanent case of the Mondays.
    I agree. Instead of grousing about how bad the code is, why not rewrite it so that it's good code? The app's been rewritten many times; every time was a chance to make it right.
  • (cs) in reply to Steven G. Aldana, PH.D.
    Steven G. Aldana:
    You know what sucks? The attitude of the jerk that commented the code. I assume he had difficulty understanding the code or maybe he was just too good to work on a legacy application. Perhaps he had a permanent case of the Mondays.
    I respectfully disagree. Sometimes, the code is structured in such a way that it's not at all clear what path it's taking until you break and look at the stack (of course, without actually seeing it, there's no way to know here).

    Given the tone of the comment in the code, it seems likely that the guy understood the code all too well, and put in such a hack so that he was able to maintain it without too much grief, and was just warning the next person to inherit it.

    P.S. If you really need to flaunt your degree, you're overcompensating...

  • nulldevice (unregistered) in reply to snoofle

    I worked with one guy who put snide remarks about his manager - some of them rather graphic, I might add - in his code comments and, at one point, the Sendmail.cf file on our mail servers. I think he kind of assumed nobody else would be working with "his" systems.

  • krupa (unregistered) in reply to FredSaw
    FredSaw:
    Steven G. Aldana:
    You know what sucks? The attitude of the jerk that commented the code. I assume he had difficulty understanding the code or maybe he was just too good to work on a legacy application. Perhaps he had a permanent case of the Mondays.
    I agree. Instead of grousing about how bad the code is, why not rewrite it so that it's good code? The app's been rewritten many times; every time was a chance to make it right.
    My question is, does the code really suck or did the comment author just think it should be done his way i.e. "the right way"?

    I've seen/heard a lot of comments from people that say such-and-such sucks but when you really press them, what they're really saying is either a) I don't understand this right away, therefore it sucks or b) I think this should be done differently, therefore it sucks.

    Whenever I encounter comments like that I typically delete them. They don't do anything to help me work with the code and I don't want to "listen" to some other person bitch all day.

  • distineo (unregistered)

    Why not just set the break point on the opening brace? "{"

    ohhh, I get it now! That would require a developer why knew what they were doing; how silly of me to assume...

    Which is the reason people at time write void randomMethod() { //code of method }

    so you can add a break on the method name (well it appears to be there though it is really breaking on the brace) plus it save space at times.

  • (cs) in reply to FredSaw
    FredSaw:
    The app's been rewritten many times; every time was a chance to make it right.
    Time being the operative word. Rewrites are usually done under the gun so "we can back to the business of business".
  • baronzemm (unregistered) in reply to krupa

    Agreed, time spent typing bitchy comments could be spend refactoring a function or adding useful debugging code.

  • distineo (unregistered) in reply to distineo
    distineo:
    Why not just set the break point on the opening brace? "{"

    ohhh, I get it now! That would require a developer knew what they were doing; how silly of me to assume...

    Breaking on function names is the reason devlopers sometimes write void randomMethod() { //code of method }

    Then you can add a break on the method name, well it appears to be there though it is really breaking at the brace on the same line. The added benifit is that you can view more lines of useful code on the screen. inread of 40 of your 150 lines being "{" or "}" you'd only have 20 lines with "}"

    bah I couldn't even understand what I just wrote, here is the corrected version.

  • Mark (unregistered)

    That code sux. Why wouldn't he use the multi-line comment notation?

  • (cs) in reply to krupa

    Sometimes it's not an option to rewrite a decades worth of code just because it sucks...I know a lot of people find that hard to believe, but if your primary business isn't code, then you as a programmer have a huge number of duties that don't include fixing something that, however evil and inefficient it is, isn't broken.

    Goes without saying that your boss isn't going to basically lose your productivity for an unspecified length of time to fix something that, if it's fixed correctly, will never even impinge on the consciousness of HIS bosses.

  • (cs) in reply to krupa
    snoofle:
    I can see doing this sort of thing. On occasion, I've been forced to do things against my will/better judgement by your garden variety PHB. If you argue (beyond a certain point), you jeopardize your job, so you just sigh, close your eyes, and warn the next person as best you can.

    Yep. I've been there a few times... Years ago, a PHB (but not my boss) asked for all execs to have domain admin rights. I briefly explained that it would be bad, and got on with life. Some months later, the same PHB came in all happy and proposed the same idea. Again pointing out that handing over domain control to the untrained is a BAD idea, he suddenly went mental and started going off about how the executives had decided it would happen, so it was going to happen. In the months after they got this permission, I started to see strange extra software popping up around the place. Some licensed, some unlicensed. Fortunately none of them have done any major damage yet... But there's potential for it (and given we can't get money to buy a tape drive that works, or even portable hard disks, there's no backups so they could kill it all).

    krupa:
    My question is, does the code really suck or did the comment author just think it should be done his way i.e. "the right way"?
    If it really was ported 3 or 4 times, I'd put my money on it sucking big time. How many layers of kludges and misunderstandings of the code would that be? I'd say at least 3 or 4!
  • (cs) in reply to Satanicpuppy
    Satanicpuppy:
    Sometimes it's not an option to rewrite a decades worth of code just because it sucks...I know a lot of people find that hard to believe, but if your primary business isn't code, then you as a programmer have a huge number of duties that don't include fixing something that, however evil and inefficient it is, isn't broken.

    Goes without saying that your boss isn't going to basically lose your productivity for an unspecified length of time to fix something that, if it's fixed correctly, will never even impinge on the consciousness of HIS bosses.

    Dosen't hurt to refactor a bit as you go.. But rewriting code for the sake of it normally benefits nobody for the effort involved. My general rule is, stick the code in and make it work, test it. Then refactor the component so it makes sense to the next person who comes along, and then test it again. Only touch code that needs to be functionally changed.

    Recently I almost broke my own rule and started to recode our credit card validation service... I thought all it did was do Luhn checks involving sql tables holding ranges, lengths etc and several thousand lines of code. I thought that was a bit insane when a Luhn check can be coded in a few dozen lines of c#, along with some basic checks to check the first couple of digits against the card type...

    What I didn't know was that over the yeas much of the code had been interwoven with loyalty card systems, and some of that code was used in the till software.

    It just wasn’t feasible, to unpick it unless there was a major business change in how we handle loyalty cards, there would have been no benefit either in recoding the credit card luhn checks as the code hadn't been touched in 5 years and other than changing a few config files holding which ranges we accepted.

  • (cs) in reply to Sr. Developer
    Sr. Developer:
    > It was as though someone had gone in and added those comments specifically to scare Michelle off.

    So, Michelle, how many other times in your life have you been within one inch of a clue and still failed to pick it up?

    (Just kidding!)

    About as many times as you've been close to being able to quote correctly but failed? ;-)

  • blinky (unregistered) in reply to Satanicpuppy

    I agree, I'm not a coder but a sysadmin. Most of the time our team is trying to keep our heads above water. We have two or three glaringly horrible problems with our network that need to be fixed, but would require our entire team to do nothing else for a week. Realistically, not going to happen. We just fix them one small battle at a time.

    I wish I had a Wayback machine so I could go tell the people that set this up to do it right. But I don't.

  • (cs) in reply to snoofle
    snoofle:
    Steven G. Aldana:
    The attitude of the jerk

    P.S. If you really need to flaunt your degree, you're overcompensating...

    Actually, PH.D is short for either the degree or Pointed-Haired Dummy... Not sure which was intended here. <g>

    Seriously, the whole point of getting a PH.D. for most people I've met was to take advantage of Mommy and Daddy's money a little longer before having to actually grow up and face real life.

  • Bob (unregistered)

    I'd say they bitched about it and didn't fix it because they follow the same rules as we do at my place of employment.

    "A line of proven crappy code is worth 10 lines of clean unproven code."

    Fact is, even if it sucks, it still works, re-writing it means it needs to be retested, and you risk inserting new bugs.

    We had to port 20,000 lines of C code into a C++ application. On top of that, the code was OSE code, and we needed it to be windows code. Our solution was basically to emulate the OSE functionallity, because the 20,000 lines of C code worked. We come in and add 5000 lines of C++ code, and yeah, there's C style casts all over the place, it doesn't conform to OO design hardly at all, but we didn't want to break the old stuff. That and there was only myself and one other guy to implement this and 9 months to do it (from forming requirements to finishing implementation), on a system that we were completely unfamiliar with, we didn't completely understand the requirements, and this application was a very small block in a very large system. (Seriously, I'm working on a different RM of the same system now, there's somewhere around 10 RMs, the one I'm working on is over a million lines of code and isn't one of the big ones :S).

  • AMerrickanGirl (unregistered) in reply to KenW
    KenW:
    snoofle:
    Steven G. Aldana:
    The attitude of the jerk

    P.S. If you really need to flaunt your degree, you're overcompensating...

    Actually, PH.D is short for either the degree or Pointed-Haired Dummy... Not sure which was intended here. <g>

    Seriously, the whole point of getting a PH.D. for most people I've met was to take advantage of Mommy and Daddy's money a little longer before having to actually grow up and face real life.

    Piled Higher and Deeper.

  • Steven G. Aldana, PH.D. (unregistered) in reply to snoofle
    snoofle:
    Steven G. Aldana:
    You know what sucks? The attitude of the jerk that commented the code. I assume he had difficulty understanding the code or maybe he was just too good to work on a legacy application. Perhaps he had a permanent case of the Mondays.
    I respectfully disagree. Sometimes, the code is structured in such a way that it's not at all clear what path it's taking until you break and look at the stack (of course, without actually seeing it, there's no way to know here).

    Given the tone of the comment in the code, it seems likely that the guy understood the code all too well, and put in such a hack so that he was able to maintain it without too much grief, and was just warning the next person to inherit it.

    P.S. If you really need to flaunt your degree, you're overcompensating...

    I didn't realize my huge degree was so intimidating. From now on I will try to keep it in my pants.

  • tragomaskhalos (unregistered)

    The real WTF is that they ported from VB to VB.NET and then to C#. Just pick one .NET language and stick to it already.

  • Shambo (unregistered) in reply to tragomaskhalos
    tragomaskhalos:
    The real WTF is that they ported from VB to VB.NET and *then* to C#. Just pick one .NET language and stick to it already.

    but all the examples in C pound...

  • JImmyDoRight (unregistered)

    Guy sounds like a read pudwhacker to me!

    JT http://www.Ultimate-Anonymity.com

  • (cs) in reply to Satanicpuppy
    Satanicpuppy:
    Sometimes it's not an option to rewrite a decades worth of code just because it sucks...I know a lot of people find that hard to believe, but if your primary business isn't code, then you as a programmer have a huge number of duties that don't include fixing something that, however evil and inefficient it is, isn't broken.

    Goes without saying that your boss isn't going to basically lose your productivity for an unspecified length of time to fix something that, if it's fixed correctly, will never even impinge on the consciousness of HIS bosses.

    There are other ways around that little political rat's nest -- developing your own skunk-works (preferably with other colleagues who realise that the application sucks) springs to mind.

    I've high-lighted your implicit assumption here, which is that the code isn't "broken." We could argue about the semantics of "broken" for many a nanosecond. In the case of the OP, however, there are indications that the data-flow is totally messed up and incomprehensible: that would be "broken," in my terms. Granted, there are probably all sorts of downstream processes involving data entry clerks that "unbreak" it, but you'd be surprised how keen PHBs are to see the results of "unbreaking" it automatically.

    Reminds me of the time I worked on an ACH (credit card reconciliation) system that got it "98%" right. What could possibly suck about that? After all, we've got processes in place to check the results manually ... for about $100 million worth of transactions a day or so.

  • Richard C Haven (unregistered)

    It is important to pass on the results of your investigation so the next person (which might be yourself in a few months) does not have to do the analysis again (whining not withstanding).

    • Beginners comment nothing
    • Apprentices comment the obvious
    • Journeymen comment the reason for doing it
    • Masters comment the reason for not doing it another way
  • jimmy (unregistered) in reply to Satanicpuppy
    Satanicpuppy:
    Sometimes it's not an option to rewrite a decades worth of code just because it sucks...I know a lot of people find that hard to believe, but if your primary business isn't code, then you as a programmer have a huge number of duties that don't include fixing something that, however evil and inefficient it is, isn't broken.

    Goes without saying that your boss isn't going to basically lose your productivity for an unspecified length of time to fix something that, if it's fixed correctly, will never even impinge on the consciousness of HIS bosses.

    Amen to that brother!

  • cranley (unregistered) in reply to krupa
    krupa:
    ...a) I don't understand this right away, therefore it sucks or...

    I would argue that if you're reading code that isn't self explanatory, it likely does kinda suck. There's a lot to be said about literate code.

  • (cs)
    She was able to make some sense of the code, but couldn't help sharing the sentiment with the Senior Developer and whichever developer had added the debugFreakinPatheticCode string.
    ...when she met the senior developer. The first thing he said to her was "the application sucks."
    I'm thinking there's a very good chance that the person who added that stuff was the senior developer...
  • (cs) in reply to Steven G. Aldana, PH.D.
    Steven G. Aldana:
    You know what sucks? The attitude of the jerk that commented the code. I assume he had difficulty understanding the code or maybe he was just too good to work on a legacy application. Perhaps he had a permanent case of the Mondays.
    I believe you'd get your ass kicked saying something like that, man.
  • Query Object: G.E.D (unregistered) in reply to Steven G. Aldana, PH.D.

    [quote user="Steven G. Aldana, PH.D."][quote user="snoofle"][quote user="Steven G. Aldana, PH.D."] snip P.S. If you really need to flaunt your degree, you're overcompensating...[/quote] I didn't realize my huge degree was so intimidating. From now on I will try to keep it in my pants.[/quote]

    In behalf of all users, we is thankful in your help.

  • krupa (unregistered) in reply to cranley
    cranley:
    krupa:
    ...a) I don't understand this right away, therefore it sucks or...

    I would argue that if you're reading code that isn't self explanatory, it likely does kinda suck. There's a lot to be said about literate code.

    Sure, but I was thinking of the situation where, for example, a person may not be familiar with the language or platform, and instead of trying to understand it, just dismisses it as "sucking".

    If the algorithm is just coded poorly and is hard to read, then yes, it does probably suck. In that case, you should just figure out what it does, clean it up, and move on.

    The overall point I was trying to make is that there are people in the world who, if they don't understand something or something isn't done the way they think it should be, dismiss it with a derogatory remark.

  • Anon Michael (unregistered)

    I knew a guy who put the flag "javasucks" all throughout his Java code. It was always set to 1, so

      if (!javasucks) {
        blah;
      }
    

    was his equivalent of commenting out code.

  • (cs) in reply to krupa

    Once I put in this comment:

    //This won't work in the year 2100 or later. I won't care because I'll be dead anyway. //See you in hell.

  • (cs) in reply to cranley
    cranley:
    krupa:
    ...a) I don't understand this right away, therefore it sucks or...

    I would argue that if you're reading code that isn't self explanatory, it likely does kinda suck. There's a lot to be said about literate code.

    Sure, if you're doing trivial stuff that you're thinking about that day. Comments should explain why the code is being done the way it is and what you're thinking. Have someone else take a look at your old code, and preferably something you had to come up with a clever solution for. If that other person has any questions for you, then you have failed as a programmer.

    The code itself should be clear enough to understand. The point of that is to use clear (but not overly verbose) variable and function names. Practical code is rarely, if ever, totally understood by just reading the code.

    Questions like, "why is transmitterToggle being turned off here?" should be answered in the comments:

    //RF interference on the RS-232 line requires that the TX is off.
    transmitterToggle = OFF; 
    

    I have written a function that was about 30 functional lines long. It had about 100 lines of comments. It was a decoder that had to go backwards if it encountered too many errors. You would have a really fun time trying to figure it out if it was commented with just the code.

  • (cs) in reply to krupa
    krupa:
    cranley:
    krupa:
    ...a) I don't understand this right away, therefore it sucks or...

    I would argue that if you're reading code that isn't self explanatory, it likely does kinda suck. There's a lot to be said about literate code.

    Sure, but I was thinking of the situation where, for example, a person may not be familiar with the language or platform, and instead of trying to understand it, just dismisses it as "sucking".

    If the algorithm is just coded poorly and is hard to read, then yes, it does probably suck. In that case, you should just figure out what it does, clean it up, and move on.

    The overall point I was trying to make is that there are people in the world who, if they don't understand something or something isn't done the way they think it should be, dismiss it with a derogatory remark.

    There are also people in this world who firmly believe that Brittney Spears can sing like an angel. I'm not too sure of your point, here.

    What we haven't seen so far is the commenting style of the original bozos. I'm guessing it's something like:

    // DO NOT TOUCH THIS CODE! // You might think that your problem can be solved by "fixing" this code. // YOU ARE WRONG! // By changing this code, you will break everything else. // This code has been carefully constructed and checked to fit every possible requirement. // DO NOT TOUCH THIS CODE! // Your problem is obviously elsewhere.

    I've anonymised that slightly, but not much. My fix turned out to be using a (horrible) manifest constant to store a pointer in a long long. Quite useful, when you're moving from a 32-bit platform to a 64-bit platform. Also quite difficult, given the lousiness of the original implementation.

    (I didn't fix the underlying concept, which was just too whacked-out for words. I have my limits.)

    This is the sort of point where throwing comments in like "This code blows Chunks of Chunk Norris proportions ... if not Bigger ... and why would anybody actually pay these retards to destroy the business?" becomes an actual Productivity Gain.

    Because, if you're not allowed to write that sort of stuff, then you're going to sit in a corner and stew for a week or so.

    Plus, when they find out you're wrong during code review, they can fire your obnoxious little ass.

  • CJ (unregistered) in reply to krupa
    krupa:
    My question is, does the code really suck or did the comment author just think it should be done his way i.e. "the right way"?

    I've seen/heard a lot of comments from people that say such-and-such sucks but when you really press them, what they're really saying is either a) I don't understand this right away, therefore it sucks or b) I think this should be done differently, therefore it sucks.

    Whenever I encounter comments like that I typically delete them. They don't do anything to help me work with the code and I don't want to "listen" to some other person bitch all day.

    I've been accused of (b), but it's hard. People who ask you to explain yourself are basically trying to call you out for being an ass, and I can't put together a list of suckiness points together in conversation. And if I were to go off and take time to organize my thoughts and come back, then I'd be the guy who wastes his time figuring out how to slam other peoples' code, as well as the guy who cares too much what people think. So frustrating.

  • (cs) in reply to CJ
    CJ:
    krupa:
    My question is, does the code really suck or did the comment author just think it should be done his way i.e. "the right way"?

    I've seen/heard a lot of comments from people that say such-and-such sucks but when you really press them, what they're really saying is either a) I don't understand this right away, therefore it sucks or b) I think this should be done differently, therefore it sucks.

    Whenever I encounter comments like that I typically delete them. They don't do anything to help me work with the code and I don't want to "listen" to some other person bitch all day.

    I've been accused of (b), but it's hard. People who ask you to explain yourself are basically trying to call you out for being an ass, and I can't put together a list of suckiness points together in conversation. And if I were to go off and take time to organize my thoughts and come back, then I'd be the guy who wastes his time figuring out how to slam other peoples' code, as well as the guy who cares too much what people think. So frustrating.

    Ah, "agile suckiness" in action.

    Do not wait for suckiness to emerge, young Jedi. Concentrate your powers before on the Force of the Suckiness.

    I'd recommend 5x3 cards, but properly calibrated sex with the elevator attendant on the way up to the meeting might work, also. Kick those endorphins in. Avoid pair programming. It's just a snare and a delusion. Generally, you do not want to have sex with your "partner" ... at least before a shower.

    Seriously: pretend it's an exam (or an interview, if you prefer), and prepare what you want to say.

    It's not difficult.

    They are uncomprehending idiots who fail at their job.

    You have the solution.

    If it turns out you're wrong about that ... well, you've learned something. And there's absolutely nothing wrong with being the elevator attendant who has sex with the next person who tries it. I mean, every job has its benefits.

  • grg (unregistered)

    Could be worse. The first program I had to work on was about 6000 lines of assembly language. With exactly one comment:

      6134     // ZAP THE CLOCK
    

    Yep, a hard-coded octal I/O instruction to a custom piece of hardware. I was able to figure out the device was number "13" and the clock's Bit9 line was getting pulsed, but that's about it. Oh, we would have worshipped snarky comments!

  • Prosthetic Lips (unregistered) in reply to Steven G. Aldana, PH.D.
    Steven G. Aldana:
    snoofle:
    Steven G. Aldana:
    You know what sucks? The attitude of the jerk that ... snip ...
    I respectfully disagree. Sometimes, the code is ... snip ...

    P.S. If you really need to flaunt your degree, you're overcompensating...

    I didn't realize my huge degree was so intimidating. From now on I will try to keep it in my pants.

    Hey, if this is you: http://www.stevealdana.com/index_contact.php (the WellSteps speaker), can I get a free copy of your bestsellers?

    Because the site says specifically,

    Don’t forget to ask for your free copies of the Dr. Aldana’s bestsellers.
    Just like the website, my quote above has the first D not in the emphasized tags, to make it look really weird.

    ;-)

  • (cs) in reply to blinky
    blinky:

    I wish I had a Wayback machine so I could go tell the people that set this up to do it right. But I don't.

    WTF is a "Wayback" machine?

  • Anon Michael (unregistered) in reply to TheDude
    TheDude:
    WTF is a "Wayback" machine?
    Goddamn kids.

    GET OFF MY LAWN!

  • (cs) in reply to Prosthetic Lips
    Prosthetic Lips:
    Steven G. Aldana:
    I didn't realize my huge degree was so intimidating. From now on I will try to keep it in my pants.

    Hey, if this is you: http://www.stevealdana.com/index_contact.php (the WellSteps speaker), can I get a free copy of your bestsellers?

    Because the site says specifically,

    Don’t forget to ask for your free copies of the Dr. Aldana’s bestsellers.
    Just like the website, my quote above has the first D not in the emphasized tags, to make it look really weird.

    ;-)

    I think you're ignoring his point. I forget what it was. But I think you're ignoring it.

    Now, I don't normally do this, but I have enormous respect for Steven G. Aldana, PH.D.

    I'm stunned by his generous offer.

    So, here's a bunch of links to charity bookshops, Steven:

    Haiti -- you too can help! Oxfam anywhere, basically. You too can help! MALAWI

    Now, Malawi is where you might be able to help. Not with your own toss-pot books, obviously. They'd be pretty useless in Malawi.

    Malawi does, in fact, need "free books." (And a way of distributing them.)

    So, here's what I propose you do:

    (1) Sell your own "free books" to other Concerned Citizens. (2) Use the money to buy books for Malawi. (3) ??? (Ed's note: I have no idea what this means.) (4) Prof ... er ... hilarity ensues ... er ... actually, you'd be doing something useful, for once.

    Otherwise, carry on being a pointless arrogant prat.

  • Sitten Spynne (unregistered)

    Honestly there's not enough information to tell us if the rest of the code sucked, but the only thing sucky here is the stupid comment that doesn't do anything. An event handler like this is useful for the purpose the commenter embellished upon: you have a text box that can get updated from several different places, and sometimes an oddball value appears; attaching this event handler to its TextChanged event and putting a breakpoint on the variable assignment lets you take a look at the call stack each time the text changes so you can see what's causing the bogus value. The variable assignment is necessary because breakpoints can only be set on code that generates instructions; I tend to use int breakpoint = 4 to make it super-clear this is just for debugging, but anything works.

    Having a text box that can be updated from so many places you can't keep track of it is a WTF on its own, but if I inherited such a thing and couldn't change it for whatever reason, I'm sure I'd write such an event handler, though for something this trivial I'd likely delete it in the production code.

    My guess is the person writing the comments was already quite frustrated with the WTFs in the application, and at this point was blaming everything for being stupid.

  • Franz Kafka (unregistered) in reply to Satanicpuppy
    Satanicpuppy:
    Sometimes it's not an option to rewrite a decades worth of code just because it sucks...I know a lot of people find that hard to believe, but if your primary business isn't code, then you as a programmer have a huge number of duties that don't include fixing something that, however evil and inefficient it is, isn't broken.

    Goes without saying that your boss isn't going to basically lose your productivity for an unspecified length of time to fix something that, if it's fixed correctly, will never even impinge on the consciousness of HIS bosses.

    Better code = easier time adding features and supporting things. Therefore, just go refactor the damned code. You start with a plan for the whole thing and implement it as changes are made. Naturally, this requires buy in from your team or it will fail badly, but this is how you fix bad code without taking the app off line for years.

  • (cs) in reply to real_aardvark
    real_aardvark:
    Satanicpuppy:
    Sometimes it's not an option to rewrite a decades worth of code just because it sucks...I know a lot of people find that hard to believe, but if your primary business isn't code, then you as a programmer have a huge number of duties that don't include fixing something that, however evil and inefficient it is, isn't broken.

    Goes without saying that your boss isn't going to basically lose your productivity for an unspecified length of time to fix something that, if it's fixed correctly, will never even impinge on the consciousness of HIS bosses.

    There are other ways around that little political rat's nest -- developing your own skunk-works (preferably with other colleagues who realise that the application sucks) springs to mind.

    I've high-lighted your implicit assumption here, which is that the code isn't "broken." We could argue about the semantics of "broken" for many a nanosecond. In the case of the OP, however, there are indications that the data-flow is totally messed up and incomprehensible: that would be "broken," in my terms. Granted, there are probably all sorts of downstream processes involving data entry clerks that "unbreak" it, but you'd be surprised how keen PHBs are to see the results of "unbreaking" it automatically.

    Reminds me of the time I worked on an ACH (credit card reconciliation) system that got it "98%" right. What could possibly suck about that? After all, we've got processes in place to check the results manually ... for about $100 million worth of transactions a day or so.

    It's a reasonable assumption that the kludge works. Kludge management is practically my specialty, and they generally work for their designed purpose.

    The issues are almost always, stability, maintainability, and performance. Many are the applications that need to be restarted on a daily/weekly basis to clear the memory. Many are the applications that are effectively impossible to maintain due to the organic growth that effects applications that evolve with changing business demands. Many, many are the applications that run in a slow and inefficient manner.

    Not so many are the ACH applications that drop 2 million dollars a day. Most people would consider that to be dramatically broken, and allocate resources accordingly.

Leave a comment on “This Application Sucks”

Log In or post as a guest

Replying to comment #:

« Return to Article