• Franz Kafka (unregistered) in reply to Grovesy
    Grovesy:
    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.

    Interesting thing here is that you gained insight in the code and presumably commented it so the next guy won't have to do the legwork. You still gained from this, and it sounds like this code would be a candidate for refactoring if you end up having to make significant changes there.

  • (cs) in reply to Franz Kafka
    Franz Kafka:
    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.

    I can't sell the Phbs on a software upgrade that will pay for itself in 3 years, and show a solid profit for 7 more.

    You act like this is merely a choice made by lazy programmers who don't want to start from scratch, but starting from scratch is costly and in a situation where it is either dedicate thousands of man hours to rewriting the application from scratch or accepting that every modification will take 2 or 3 times as long, the phb is going to pick the latter option every time, even if, even if the man hours lost to modifications will outstrip the time needed to do a rewrite in a few budget cycles.

    You have to understand that no boss wants to take on the headache of a new system, with all of its inevitable bugs, without a good reason. And when the reason is something like "its hard to modify" you will not get permission to do the rewrite.

  • (cs) in reply to KenW
    KenW:
    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.

    A doctor of philosophy is Ph.D., not PH.D. Maybe he was being sarcastic, like "Wile E. Coyote, Super Genius".

    Most Ph.D.'s I know (in science and engineering) spent five years in near poverty living on stipends rather than earning 3 to 5 times as much in industry. The reasons to do so include love of learning, procrastination, more time to party like a college student, and avoiding crappy entry-level jobs.

  • Franz Kafka (unregistered) in reply to Satanicpuppy
    Satanicpuppy:
    Franz Kafka:
    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.

    I can't sell the Phbs on a software upgrade that will pay for itself in 3 years, and show a solid profit for 7 more.

    You act like this is merely a choice made by lazy programmers who don't want to start from scratch, but starting from scratch is costly and in a situation where it is either dedicate thousands of man hours to rewriting the application from scratch or accepting that every modification will take 2 or 3 times as long, the phb is going to pick the latter option every time, even if, even if the man hours lost to modifications will outstrip the time needed to do a rewrite in a few budget cycles.

    Read what I wrote again: I'm not calling anyone out, nor am I suggesting you start from zero. I'm saying that this is how you can make the code better. All you need is a plan for the architecture that people buy into and the will to refactor towards that goal as part of your normal maintenance.

    You have to understand that no boss wants to take on the headache of a new system, with all of its inevitable bugs, without a good reason. And when the reason is something like "its hard to modify" you will not get permission to do the rewrite.

    It's hard to modify means more bugs and longer feature changes, so sell them on that. Pay me now or pay me later.

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

    I think the problem is that it's very hard to impress on your average PHB (even if you're lucky enough to have a boss who was once a programmer!) how hard it is to maintain lousy code. You can bitch till you're blue in the face about how fragile the legacy application is, and how any change will bring the house of cards crashing down around your head, but 9 times out of 10 they won't believe you until it actually happens. It's hard for them to estimate the liability imposed by working-but-crappy software, so they just don't.

  • (cs) in reply to Satanicpuppy
    Satanicpuppy:
    Franz Kafka:
    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.

    I can't sell the Phbs on a software upgrade that will pay for itself in 3 years, and show a solid profit for 7 more.

    You act like this is merely a choice made by lazy programmers who don't want to start from scratch, but starting from scratch is costly and in a situation where it is either dedicate thousands of man hours to rewriting the application from scratch or accepting that every modification will take 2 or 3 times as long, the phb is going to pick the latter option every time, even if, even if the man hours lost to modifications will outstrip the time needed to do a rewrite in a few budget cycles.

    You have to understand that no boss wants to take on the headache of a new system, with all of its inevitable bugs, without a good reason. And when the reason is something like "its hard to modify" you will not get permission to do the rewrite.

    Oh dear.

    (1) Depreciation/Amortization. Built in. Roughly three to four years, depending upon accounting. Try harder. (2) No obvious reason to start from scratch. Try harder. (3) Try to explain to your boss how he/she will have less headaches. Try harder.

    (4) Do your best not to be a total wuss.

    I don't have high hopes on any of those, but, y'know? I told you so.

  • Yosemite Sam (unregistered) in reply to tin
    tin:
    ... 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).
    Well, if my software licensing was under control prior to the execs getting Domain Admin privileges, I suspect I might've actually called the BSA. Mahogany Row might actually get a clue about the business value of *not* having admin privileges.

    Oh, and during the kerfluffle, you could let top-level investors know there was no backup system protecting their investment.

    ... might want to have your resume (or a job offer!) in hand before pulling the trigger on either of these, though.

  • IcyLiquid (unregistered)

    What is this? I can't debug this. There's no code here!

    FREAKING THING SUCKS! **** IT! WE'LL DO IT LIVE!

  • (cs) in reply to TheDude
    TheDude:
    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?

    Ask a dog and his boy.

    Rocky: "It looks like we're in real trouble this time." Bulwinkle: "Good, I hate that make-believe kind."

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

    If it's not maintainable, it's broken. The way to fix that is not in one big gulp, but in lots of little needle pricks. Each time you come across a thing that is backwards, make that particular instance not backwards. Re-factor a single global variable in a day. Keep up the bill-paying work velocity, and make sure you make non-zero forward progress on re-factoring over time, and over time, the application will suck less.

  • Smoucher (unregistered)

    OK, this is C# code. It's a handler for a controls TextChanged event. It looks like it was generated by a wizard (i.e. the 'normal' way of developing in C#). Somewhere will be a line of code which is referencing txt_fld_TextChanged, it probably looks like this

    some_ctrl.TextChanged += new EventHandler(txt_fld_TextChanged); (or similar, sorry don't have my C# hat on right now)

    Aside from the fact the the control is probably named 'txt_fld', if the idiot managed to hook up a delegate to its text changed event, surely he can track down where the other references to the object are.

    I guess the WTF here is that the comments are the WTF instead of the code, but it's hard to tell from the article.

  • (cs)

    How about an analogy? I live in an old house. It's drafty, the wiring is sub-standard, the septic tank won't meet current codes (but is ok because it's grandfathered), it has termite damage, the front porch is falling apart, nothing is square, plumb or level, it needs to be painted, the basement windows are a disaster and it's poorly insulated. In short, you can make a valid argument that my house "sucks." But I doubt any of you in my situation would tear down the whole building and rebuild from the ground up just so you can install air conditioning.

  • wesley0042 (unregistered) in reply to Fister
    Fister:

    Each time you come across a thing that is backwards, make that particular instance not backwards. Re-factor a single global variable in a day. Keep up the bill-paying work velocity, and make sure you make non-zero forward progress on re-factoring over time, and over time, the application will suck less.

    Especially compared to adding hundreds of lines of "why this code sucks" comments like the developers in TFA did. Talk about contributing to the problem!

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

    No need to keep it in your pants if you wipe when you are done...

  • vereor (unregistered) in reply to TheDude
    TheDude:
    WTF is a "Wayback" machine?
    http://www.archive.org/web/web.php ?
  • bat (unregistered)

    Well, only one line of that comment is rude. I usually comment the code in detail, so that the next person who will read it, will know what it is meant to do. It happenned several times that some "smart" programmers have deleted part of the code, just because they did not understand it or thaught that they could do better, then asked for help.

  • Manic Mailman (unregistered) in reply to James
    James:
    You can bitch till you're blue in the face about how fragile the legacy application is, and how any change will bring the house of cards crashing down around your head...
    So it's fragile and any change will bring it crashing down, and you want to go around refactoring it - just because?

    It's one thing if there are unit tests that'll validate that your changes don't bring things crashing down, but this sounds like one of those legacy applications that really does fit the 'if it ain't broke, don't fix it' mantra.

    I don't know about you, but I've worked on systems where it seemed that if you even looked at code in one part some other seemingly completely unrelated area would break. For those systems, you don't change things unless there's a specific requirement (bug fix or a planned rewrite). It's not a wonderful situation, but it is what it is.

  • Manic Mailman (unregistered) in reply to bat
    bat:
    It happenned several times that some "smart" programmers have deleted part of the code, just because they did not understand it or thaught that they could do better, then asked for help.
    That sounds similar to the situation that caused the Debian OpenSSL key creation vulnerability (though they apparently did perform due diligence on the change and got bad information/advice):

    http://wiki.debian.org/SSLkeys#head-76415d1c2f25f12ebbcc99bb93959a97f18e3b88

  • BillyBob (unregistered)

    If there is one truth in software, it is that all software sucks. I'm yet to hear a single developer who thinks the stuff they work on rocks...

    The only exception to this is Windows XP which sucked until Windows Vista was released, it was then considered to be a solid OS.

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

    I can see it now, aging is cured you have a several trillion dollars (thanks to inflation) and are about to get on your space plane and finally retire to the beaches of Antartica, when you get arrested and tortured. It turns out the date bug you left in the system that is now tightly integrated into the CIA (complete information awareness) system and causes your name to popup next on the "citizens are terrorists" interrogation list.

  • Hans (unregistered) in reply to TheDude
    TheDude:
    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?

    It is a type of TARDIS.

  • (cs) in reply to karma
    karma:
    I can see it now, aging is cured you have a several trillion dollars (thanks to inflation) and are about to get on your space plane and finally retire to the beaches of Antartica, when you get arrested and tortured. It turns out the date bug you left in the system that is now tightly integrated into the CIA (complete information awareness) system and causes your name to popup next on the "citizens are terrorists" interrogation list.
    He needed a space plane to get to Antartica? Must be a new planet somewhere in the nether reaches of the milky way. If it had another "c" in the spelling, he wouldn't need that space plane; just a good icebreaker. Assuming our starting location is planet Earth, you understand. If it was Jupiter, maybe a Prius, but he's going to spend all those trillions on fuel.
  • Iwein (unregistered) in reply to krupa
    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.
    Option b.

    Most code I've seen sucked. In many cases it didn't suck as hard as I thought at first, but on closer inspection it sucked almost without exception. Otherwise there is no point in paying a developer to work on it is there?

    Mind you I have seen some code that didn't suck, but usually I stop looking there and just use it.

    Option b is a really common an viable reason to be changing somebody elses code imho.

  • OBloodyhell (unregistered)

    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.

    When you are dealing with Moldy Swiss Cheese code, you may not have time to chase down all the interlocking bugs, fixes, tweaks, workarounds, and general overall kludges -- since fixing one can cause cascade errors to other code which was written to "fix" a problem which your fixes have now eliminated -- and thus triggers said "fixes" to crash the program.

    At certain points, the fix process is as time consuming as a full re-write, which your own job requirements and/or management may not allow for.

    "Hey, it's working, leave it alone" is often the only perception of point-haired management types. That it's a house of cards disaster waiting to happen is something they choose to remain vigorously ignorant of.

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

    If it's not maintainable, it's broken. The way to fix that is not in one big gulp, but in lots of little needle pricks. Each time you come across a thing that is backwards, make that particular instance not backwards. Re-factor a single global variable in a day. Keep up the bill-paying work velocity, and make sure you make non-zero forward progress on re-factoring over time, and over time, the application will suck less.

    Great idea, I have the joy of being responsible for maintaining a nice old C monster. I would really like to see how you upgrade it into something that doesn't invoke nightmares.

    I'm sure you could remove a global variable in just under 3 hours. (Hm, makes me wonder if there are any limits to the number of variables you can pass to a function)

    The problem is that the whole program was designed with bug oriented programming in mind. (or at least that is the only explanation I can think of for some of its "features")

  • Edward Royce (unregistered)

    Hmmmm.

    Maybe I'm a masochist but I frankly enjoy stuff like this. You come into a tough situation, find a shitty application or system and then rework it into something nice, clean and elegant.

    Much more satisfying IMO than creating something from scratch because it's much more challenging.

    Then again I also enjoyed programming in RPG and assembler so the masochism theory is still in play. :)

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

    GET OFF MY LAWN!

    Yeah it does make you feel pretty damn old doesn't it?

  • Edward Royce (unregistered) in reply to n9ds
    n9ds:
    How about an analogy? I live in an old house. It's drafty, the wiring is sub-standard, the septic tank won't meet current codes (but is ok because it's grandfathered), it has termite damage, the front porch is falling apart, nothing is square, plumb or level, it needs to be painted, the basement windows are a disaster and it's poorly insulated. In short, you can make a valid argument that my house "sucks." But I doubt any of you in my situation would tear down the whole building and rebuild from the ground up just so you can install air conditioning.

    Prime candidate for renting out!

    1/2 off first month's rent!

  • Edward Royce (unregistered) in reply to vereor
    vereor:
    TheDude:
    WTF is a "Wayback" machine?
    http://www.archive.org/web/web.php ?

    http://en.wikipedia.org/wiki/Wayback_machine

  • Edward Royce (unregistered) in reply to karma
    karma:
    themagni:
    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.

    I can see it now, aging is cured you have a several trillion dollars (thanks to inflation) and are about to get on your space plane and finally retire to the beaches of Antartica, when you get arrested and tortured. It turns out the date bug you left in the system that is now tightly integrated into the CIA (complete information awareness) system and causes your name to popup next on the "citizens are terrorists" interrogation list.

    You need to have less imagination.

    And caffeine.

  • (cs) in reply to Franz Kafka
    Franz Kafka:
    Satanicpuppy:
    Sometimes it's not an option to rewrite a decades worth of code just because it sucks

    Better code = easier time adding features and supporting things. Therefore, just go refactor the damned code.

    Indeed. We have been in the same situation really. It started when around 2001 a downright IDIOT wrote a piece of code. This person had very little programming experience and no formal education in CS or anything like that. The business started slowly, but eventually it started making money. There always were problems with that particular piece of code. Sometimes it would crash completely, at other times it would hang and in between it sometimes would just not registrate something when it was supposed to do so.

    During the years, fix upon fix was applied to the code, making it such a monstrosity that nobody knew what the code exactly was doing. There were tons of methods with totally incomprehensible names, with in them loops nested to 10 levels deep. When looking closer at the code, these loops stated to look suspiciously familiar after a while and it turned out the same 100 line nested loop mayhem had been copy/pasted a few dozen of times with only some slight changes every time.

    To make matters worse, approximately 70% of all code simply did nothing. It were just leftovers from copy paste actions. To call any give method on a class, you first had to assign a couple of values using public instance variables of the class, a couple through getters and then also pass a couple directly to the method. And if you think this was bad, consider the fact that the original programmer did not know the programming language had something like types and made everything a String. Also, this programmer had the insidious habit of giving random names to his variables. A customer ID would be called "rabbitID" at one location and "proofOfIntendID" at another. To really finish the job, a variable called customerID would often actually hold the product ID, but not always...

    And in case anyone even thinks I'm making any of this up; the actual situation was even worse than this!

    In some magical way however, after a few years the code worked. For about 95% of the cases...

    Recently this idiot programmer announced that he would be leaving the company. This is probably a good thing for the company, but the problem is that this abomination of code that he created runs at the core of our business process. At some point of time it undoubtedly needs to be fixed again. It also undoubtedly needs to be extended with new features as it really is the kind of code that needs to accommodate an ever changing market.

    Since no programmer in our company, from the highest ranking "I know everything" senior to the lowest ranking "I'll do anything" junior wants to touch the code, there simply is no way around to rewriting it.

    Yes it works now (in a way) and yes it's critical to our business. But if we don't start rewriting it -now- we might run into some very serious issues even a few months from now...

  • Steve (unregistered) in reply to TheDude

    WTF is a "Wayback" machine?

    http://www.justfuckinggoogleit.com/

  • Grig (unregistered)

    I used to toil through code like that with testing software. We used a massive script system that manipulated Windows GUIs, and the scripts were full of comments like that:

    Here we have to grab not only the main window, but scan to see

    Which is the Okay button. Sometimes it's a graphic, sometimes

    an actual button. What fun it must be to work for this company's

    UI!

    and some were mean:

    You may not know why this subroutine exists, but it's called

    everywhere for a reason. Wanna know why? Because some WINDOWS

    FUCKTARD who doesn't ASCII from ANSI, who were shitting their

    diapers when modems still did 300 buad, and so they think that

    ANY character over 127? Doesn't exist. Poof! International

    letters? Please! Speak American! I hate them. And so when

    "weird squigglies" started appearing in his forms, well, nuts to

    that! Turn them all into "space." But he made this transparent

    so a lot of the text generated looks like a space, but might

    be 0xB4, and NOT 0x32, so scanning for "words" is fucked up

    because of all these non-standard "spaces" that aren't.

    I knew the guy who wrote those comments, and I actually liked him.

  • (cs) in reply to Query Object: G.E.D

    [quote user="Query Object: G.E.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.

    [/quote]

    Allyou're titlez are belong to us.

  • (cs) in reply to Prosthetic Lips
    Prosthetic Lips:
    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.

    ;-)

    This site suckx

  • a (unregistered)

    I'm a bit alarmed by the relativism expressed in this discussion.

    There sure is sucky code "out there". Code that works just because of chance and luck. Code that is unreadable. Code that was written by someone who really didn't understand the programming language, the used libraries or even programming in general.

    Sure, you can take 'oh, this is a horrible kludge'-type comments too far, but really, they have value.

    The thing to look out for is a developer who thinks ALL projects except his own suck. That person probably is just bad at reading other peoples code.

    But a person who comments, say, 10% of code he maintains in that way is not someone I would be suspicious of at all. Heck, in some corporations I think >50% of the code would benefit from warning-comments....

    I sure am glad to work on a non-WTF-company at the moment though...

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

    No, it isn't always an option to rewrite a decade's worth of code, but it should be. No matter what the other business priorities are, if you have code that is horribly written and difficult to debug, the amount of time and money spent on fixing problems with it is reduced drastically, not to mention the time spent training new people on the code or letting them work out how to debug it. If you don't have the time to do it, time should be made, because if it isn't it'll just get worse and worse, and it's only a matter of time before it blows up in your face. All it takes is one big problem that takes months to fix for it to be worth it.

  • (cs) in reply to Fister
    Fister:
    Satanicpuppy:
    ...don't include fixing something that, however evil and inefficient it is, isn't broken.
    If it's not maintainable, it's broken.
    Stop thinking like a programmer and start thinking like a person with a job to do. If this is an in-use piece of software, and it performs exactly the task the users require it to with acceptable performance, they didn't give a wet fart what it's like to maintain - it WORKS. It will only be broken when it stops doing what they want (i.e. once you've decided to poke about with it and make it "better").
    Smoucher:
    if the idiot managed to hook up a delegate to its text changed event, surely he can track down where the other references to the object are.
    Correct me if I am wrong, but I believe the issue was that a text field was being updated but no-one could figure where from? Given this was ported at least 3 times (thats ported not redeveloped - if it's like any other application that means a layer of onioned-on changes, then a port to a new language, then another layer of onioned changed, then another port, then another set of onionings - thats three different sets of added functionality in three different(ish) languages so three different ways of doing things) BEFORE the whole thing was put into C-Hash. So, in my estimation, that's six layers of kludge before any changes made to the C# version. And you wonder why it's so hard to track down every reference to every text field? I wish I had your brains...
    Manic Mailman:
    I don't know about you, but I've worked on systems where it seemed that if you even looked at code in one part some other seemingly completely unrelated area would break. For those systems, you don't change things unless there's a specific requirement (bug fix or a planned rewrite). It's not a wonderful situation, but it is what it is.
    That's a very familiar situation. I've just started working with a small research group that publishes data online, and the reporting format for some of the data changed a few weeks before I started (great timing or what?). I figured that I could ignore the reports that didn't have a new format, because hey, they hadn't changed and the old reporting system should still work! Boy was I suckered. We uploaded the data for those reports that were still in the old format (plus the appropriate lookup tables etc.), pulled up the website, and *boom*, exceptions everywhere. When I dug into it it seemed that each report looked for data for all possible reports (even though each report had its own table in the database, and the database was full of SPs that only generated data for a single report). As the same pages produced both the current reports and the archive reports, I would've had to go through and refactor every old-style report to remove the references without breaking the report archives. In the end I left it be and rewrote those reports that still needed to use the old style formatting. I did, however, resist the temptation to write snarky comments on the old code then submit it to this fine website!
  • Johnny Canuck (unregistered) in reply to snoofle
    snoofle:
    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.

    The last place I worked, I left a large amount of comments similar to this. But mine were more along the lines

    // The obvious solution to this problem would be to implement data locking in the table during processing.
    // However, (Name omitted) has insisted the solution is to implement a duplicate table, store the changes in the duplicate and then check for conflict after. // (Name omitted) told me not to use the built in DB features and do it this way because that's the way they always used to do it.

    And the reason I specifically put those in the code was because I knew later coders would be looking at my work and saying "Why the heck would you do something so stupid?" I wanted them to know I knew better and to also give them a heads up as to why they were done the way they were.

  • Bill O'Really (unregistered) in reply to IcyLiquid

    ROTFLMAO

  • diesel (unregistered)

    The real WTF here is that they left DEBUG code in with PRODUCTION code. It isn't even Debug.Writeline() or anything. What is the point!

  • Jonathan (unregistered) in reply to IcyLiquid

    Lol reminds me where I used to work before where that senior developer kept complaining about our code but never tried to teach us anything. He should try and help ..and that is why he is a senior developer no ?

  • Rabiator (unregistered) in reply to Manic Mailman
    Manic Mailman:
    James:
    You can bitch till you're blue in the face about how fragile the legacy application is, and how any change will bring the house of cards crashing down around your head...
    So it's fragile and any change will bring it crashing down, and you want to go around refactoring it - just because?

    It's one thing if there are unit tests that'll validate that your changes don't bring things crashing down, but this sounds like one of those legacy applications that really does fit the 'if it ain't broke, don't fix it' mantra.

    That's fine if you can expect that the application won't be extended anymore. But if you can already predict that you'll have to add a bunch of features next year, now might be a good time to refactor.

    But like James, I'm working at a place where management does not see value in refactoring...

  • Someone (unregistered)

    If the angry developer had spent as much time refactoring the code as they did writing that novel of comments, perhaps it wouldn't suck so much.

  • g (unregistered)

    OK, so we have someone who doesn't know what is changing the text in a textbox, so they add a bunch of crap code for debugging purposes. THAT is a WTF. And, it isn't even in a conditional compile statement.

    This is C# code, so one possibility is that the original developer used DataBinding to implement a coupling between the data and UI. Standard UI practice. In this case the person adding the comments is an idiot.

    Or, there are calls to set the Text property explicitly, in which case it is possible to register an anonymous delegate in the immediate window of Visual Studio that performs a Thread.Sleep, allowing you to pause the execution in Visual Studio and view the stack trace without having to pollute your code with a bunch of crap.

  • Gill Bates (unregistered)

    At least there is some comments! haha.

    Where I am right now, reading a few lines of code, you can come to the same conclusion...you dont have any comments to warn you or scare you. But for even general good practice of commenting your code, there's not of that here. You actually have to do some CSI (code snippet investigation) before you come to the conclusion..."This Application FREAKIN Sucks!"

  • Kotaro24 (unregistered)

    Found this on a piece of interface code that has been failing for the last week:

    '********************************************************************* '*** '*** NASA SAYETH: BETTER, FASTER, CHEAPER. PICK TWO. '*** (I.T. Translation: SOLID, EFFICIENT, RAPIDLY-DESIGNED. PICK 2). '*** '*** $CIO chose BETTER and CHEAPER (less develepment time). '*** '*** The end result is that this code is abysmally slow. '*** '*** Some areas needing re-write:

    Followed by a list of a half-dozen places where refactoring would speed up the code.

  • itsmo (unregistered) in reply to n9ds
    n9ds:
    How about an analogy? I live in an old house. It's drafty, the wiring is sub-standard, the septic tank won't meet current codes (but is ok because it's grandfathered), it has termite damage, the front porch is falling apart, nothing is square, plumb or level, it needs to be painted, the basement windows are a disaster and it's poorly insulated. In short, you can make a valid argument that my house "sucks." But I doubt any of you in my situation would tear down the whole building and rebuild from the ground up just so you can install air conditioning.

    Go for it - probably most of the money value is in the land anyway - that house needs to be burnt to the ground to rid the area of termites!

  • Hannes (unregistered)

    I once left pretty rude comments in a legacy app, too. It was some madness like "we want to know if a certain value is in a certain column in the database, so we query for the ENTIRE FRICKIN' TABLE and do a for loop OVER EVERY FRICKIN' ROW and if we found the value, we set a flag to 'true' but WE WILL CONTINUE TO LOOP THROUGH THE ENTIRE RESULT SET because we already got it from the DB, so we can at least look at it, right?"

    Followed by some more madness where EVERY FRICKIN' ROW of a DataGridView got checked for value changes if you changed only one row. This is okay if you only have 3 or 4 rows, but with a few hundred rows it really slows down the whole application (worst thing: None of the users ever thought about complaining why the app is so damn slow, I found out about it by pure accident).

    I left a rude message, scolding the old developer and replaced it with something more efficient. But a few days later when I looked at it again, I simply deleted the old code and the comments, just leaving explanatory comments of why I chose to do things the way I did them. I figured that a) it's never a good idea to have rude comments in your code; b) they wheren't very helpful and c) I didn't want to come accross as an arrogant "know-it-all". If I made mistakes in my code (and I'm pretty sure I left behind some VERY bad code) I'd appreciate if someone just explained to me why it was bad and how I can make it better in the future.

    So yeah, I agree with what has been said: Comments like this should NOT be in any codebase.

Leave a comment on “This Application Sucks”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article