Your Standards Are Too High

« Return to Article
  • Frosh 2012-11-20 08:20
    Not the frist time I've seen code that bad.
  • Ama 2012-11-20 08:21
    The code was working, they had other priorities to code first. Where's the WTF?
  • grabah 2012-11-20 08:22
    if it works it works.
  • Fingie 2012-11-20 08:22
    Ama:
    The code was working, they had other priorities to code first. Where's the WTF?


    Maybe this is a case of sloppy WTF.
  • Remy Porter 2012-11-20 08:24
    The real WTF is how often people look at unmaintainable code and say, "Meh, it works, right?"
  • Cursorkeys 2012-11-20 08:25
    Ama:
    The code was working, they had other priorities to code first. Where's the WTF?


    Probably the manner of the reply?

    It's one thing to say items x,y and z are ahead of refactoring in the queue of things-to-do but chiding someone for even thinking it needed to be addressed smells of a bad development culture.
  • furiant 2012-11-20 08:26
    Seemingly satisfied with this story, I nod in apparent satisfaction as I jot down this quick comment.
  • letatio 2012-11-20 08:33
    What the other developers were saying had some truth to it. They failed in expressing what they meant. Any skilled developer with a few years experience knows that as a rule of thumb, don't fix it if it isn't broken. Re-factoring anything is a sure way to introduce new bugs.

    However, there are sometimes better ways to remedy this. Did the developer propose that they move towards TDD?
  • LoremIpsumDolorSitAmet 2012-11-20 08:37
    It looks like Mark Bowytz has created his own (more manly) version of Cornify. Click on "emergency bug"!
  • Meep 2012-11-20 08:39
    Remy Porter:
    The real WTF is how often people look at unmaintainable code and say, "Meh, it works, right?"


    What you do is realize:

    a. if you break it, you're the fuckup

    b. other people will keep writing more shit code.

    So you conclude that you'll just try to keep your code clean.

    Until people shit all over that, too.
  • Meep 2012-11-20 08:42
    The hiring manager cocked an eyebrow and replied, "What about a scenario where it's 2 in the morning and you have to apply an emergency bug fix ASAP. Sometimes, to get things moving, maybe you have to cut an occasional corner?"


    If it's an emergency, then it really needs to be done right or you'll wind up having to patch the patch. It's the "do no harm" principle: you never knowingly commit deficient, uncommented or untested code.
  • TGV 2012-11-20 08:45
    The indent is way too big. I could never work there.
  • some random cat 2012-11-20 08:52
    Ama:
    The code was working, they had other priorities to code first. Where's the WTF?


    Relax your high standards about WTFs, man
  • ubersoldat 2012-11-20 08:53
    stmtInsertToTarget.setInt(1, rsSource.getInt(1));


    TRWTF is limiting your application to Integer.MAX_VALUE records.
  • jonnyq 2012-11-20 09:00
    Ama:
    The code was working, they had other priorities to code first. Where's the WTF?


    I came here to say this.

    If you came in a meeting and said "Hey, let's take this ugly code that works and spend 4 or 5 hours rewriting it so that it's not ugly" I'd respond the same way. Yes, it needs to be done, but 4-5 hours worth of code changes will have to be followed with 9 or 10 hours of testing. And if there is even ONE bug... one little tiny bug in the refactored code, there's going to be bitching from some other department about why we "fixed" something that wasn't broken.

    So, yes, put in a ticket to get it fixed, but that ticket will be a much, much lower priority than all the other things that need to get done.

    Now, on the other hand, if there is even ONE bug with big ugly code, you now have an excuse to make some changes, and in the midst of those changes "sneakily" clean up the surrounding ugly code in the name of bug fixing :)
  • ColdHeart 2012-11-20 09:01
    I think this and many other examples point out how important it is to ask an interviewer about the practices of the company.

    It's one thing to say "We have other priorities atm, so that can wait" and "if it aint broke, don't fix it". With something like this, fixing it now can help adding to it later.
  • Steven Seagal's ponytail 2012-11-20 09:02
    Meep:

    What you do is realize:

    a. if you break it, you're the fuckup

    b. other people will keep writing more shit code.

    So you conclude that you'll just try to keep your code clean.

    Until people shit all over that, too.


    Having worked in a "legacy" environment, this was exactly the mindset that I fell into. However, the old dinosaurs would jump all over my code for using newer features of the language because they didn't understand it. I think I still have scars from some of those battles.
  • Foo Bar 2012-11-20 09:03
    Refactoring that code (and its numerous siblings) with something more versatile and generic would almost certainly result in a net decrease in LoC, therefore bad.

    Unroll ALL the loops!
  • peter 2012-11-20 09:06
    Ama:
    The code was working, they had other priorities to code first. Where's the WTF?


    The problem with this approach is that, a handful of years or so down the line, the codebase will be an impenetrable mess, and simple maintenance will be a task much more daunting (and time-consuming) than refactoring would have been now. Also, it will suck the will to live out of the developers that are responsible for maintenance.

    On top of that, the harder it is to figure out what unreadable code, written by people who are no longer around, does, the more insurmountable the task of refactoring it will be.

    Don't ask me how I know this.

    captcha: abigo: a big null?
  • MuTaTeD 2012-11-20 09:14
    I inherited the similar db access code when I joined my current employer as team lead. It took me almost a year to convince the client that this section needed to be refactored and in the mean time I left this section to the developer who was already working when I joined.

    Finally after one year of convincing the client and with the application crashing on database crashing when the application went multi-threaded, they finally agreed. I spent 2-3 days on the actual refactoring including the planning phase and a couple of days more for testing out the changes.

    Now I am happy to say that the database section is quite solid and can handle simultaneous operations without much complaints.
  • Mike 2012-11-20 09:16
    So it seems as if the interviewer knows of the problem and is hiring people who may be able to fix it, yet has no ability to change the culture to enable that to happen.

    Management failure, sack the beardies.
  • AGray 2012-11-20 09:38
    ubersoldat:
    stmtInsertToTarget.setInt(1, rsSource.getInt(1));


    TRWTF is limiting your application to Integer.MAX_VALUE records.


    Could be Decimal.MaxValue instead. Still gives you 999,999,999,999,999,999,999,999,999,999 records, provided it's never negative. (If it's negative, then you've got a measly 999,999,999,999,999,999,999,999,999 max records to work with. Rats.)

    CAPTCHA: duis. Dissidia: Duisdecim...
  • AGray 2012-11-20 09:40
    AGray:
    Could be Decimal.MaxValue instead. Still gives you 999,999,999,999,999,999,999,999,999,999 records, provided it's never negative. (If it's negative, then you've got a measly 999,999,999,999,999,999,999,999,999 max records to work with. Rats.)


    ...EDIT: I was wrong. Decimal ranges from: -79,228,162,514,264,337,593,543,950,335 to 79,228,162,514,264,337,593,543,950,335. Sorry about that.
  • Dave 2012-11-20 10:02
    It was my first real developer job, which means that instead of writing code "under the radar" to help me do the sys admin stuff, I was actually hired to write code.

    During the interview I asked "Do you have written coding standards?" "Oh yes of course." they said. I neglected to ask "Do you follow them?"

    I found out that all my co-developers had no training in development, or software lifecycles, or anything to do with I.T. at all. No, instead they were all proud of their Manufacturing certifications, which I, to their disdain, did not have.

    The code was a mass of unreadability due in part to the habit of cutting one or a few lines of code from this module and pasting them into that module without paying any attention whatsoever to the indent level. Fortunately the editor had a built-in "reformat" command which no one had ever been curious enough to discover. I gradually tidied things up as I touched one program after another.

    When it came time for the next release, a shitstorm arose. I learned that our "customer service" people would take a tape (yes) of the software to each customer and install it. However, they'd all made custom tweaks at each location which of course would be overwritten by the new version.

    The standard practice for this dilemma, unique in the software industry and thus never before solved elsewhere, was to run a "diff" on the customer's version vs. the new release, and manually decide which lines to keep or replace. But with the reformatted code, every line was different! The "customer service" people wanted to kill me.

    OK in retrospect I decided to make a change to production code without knowing all the ramifications. Live and learn.

    But I showed them "diff -w".

    Years in business, dozens of "developers" and "customer service" people, and nobody had ever bothered to RTFmanpage!
  • Cbuttius 2012-11-20 10:04
    The code looks WTF'y but I challenge the posters here to write the fix.

    You'd ideally want a schema object, that will run through the various possible types.

    Also please show me how this schema adds any improvement, given that you are going to populate it anyway somewhere. Hard-coded?

    By the way, it is a huge issue I have with this site that you cannot see the article whilst you are writing your comment (unless you open another browser window, of course).
  • ObiWayneKenobi 2012-11-20 10:15
    This story reminds me of two things:

    1) In July I was let go from a job I had been at for around 2 years because I, like Michael in the story, constantly pushed for us to refactor our crufty legacy code. Our application was a public facing website that received several thousand hits per day, and often would crash 4-5 times a day on average. We actually had three developers leave in three weeks because our ideas were shot down. I was the "last man standing" and got blindsided after buying into the lies I was being fed about fixing things and being promoted to lead.

    2) A week after I left, I heard through the grapevine that they hired someone who took one look at the code and quit, saying he expected them to have better standards. I think he was there a day, if that.

    Sadly, places like that never learn. The longtime developers tend to get lazy and complacent and jealous of any new person who brings in outside ideas (for fear of being shown up) and invariably the new person gets fed yo and quits or is fired because they alone want to improve. Meanwhile, the company continues to pump out crap, blissfully unaware of anything wrong.
  • iMortalitySX 2012-11-20 10:20
    Ama:
    The code was working, they had other priorities to code first. Where's the WTF?


    Just to quote the most quoted post here today... Anyways, the real WTF is the future. I worked on a legacy applicaiton which had some great code that was very similar to this. Then one day the customer came out and said that they needed everything moved to a server and the client applicaiton should talk to the server over a secure channel. WCF is awesome, but trying to tear appart the old code to hook in your new code when there are no kidding 100's of different bad ways to do it. That was no fun at all, and took nearly 3x the amount of time it should have to implement the new service.

  • Chelloveck 2012-11-20 10:21
    Steven Seagal's ponytail:

    Having worked in a "legacy" environment, this was exactly the mindset that I fell into. However, the old dinosaurs would jump all over my code for using newer features of the language because they didn't understand it. I think I still have scars from some of those battles.


    Heh. I was once told by an older programmer not to use the C ternary operator because "no one understands it". You know, the one that goes:


    foo = (bar > 0) ? baz : qux;


    Yeah, there's a brainteaser for you...
  • Noob 2012-11-20 10:21
    I really, really hate when the new guy feels the need to point out the obvious and then expects a big pat on the back.

    Yeah - gee - nobody here thought that refactoring messy code would be a good idea. It's not that there isn't a business case or other priorities or anything; we just never thought of it. You must be super good.

    Every place I've ever been at could benefit from...
    * Additional time to refactor
    * Additional testing
    * Additional documentation
    * Additional automation

    It's trivial to walk into a place, spend a day observing, and point out the obvious.
  • Cbuttius 2012-11-20 10:23
    Ok, we don't know the language for certain but it could be C++. Let's try a macro. We'll need to use token pasting (##) to paste Int String or Float to the end.

    Let's get rid of the counting by introducing a number that gets incremented. For the purpose of sequence points we should increment in a separate statement from the main one.


    #define STMT_INSERT_FROM_RSSOURCE(type,var) \
    stmtInsertToTarget.set##type(var, rsSource.get##type(var)); \
    ++var

    then in our code

    while( rsSource.next() ) {
    int field = 1;
    STMT_INSERT_FROM_RESOURCE(Int,field);
    STMT_INSERT_FROM_RESOURCE(Int,field);
    STMT_INSERT_FROM_RESOURCE(String,field);
    // ...
    stmtInsertToTarget.addBatch();
    }


    Ok. Of course I started with a solution I don't like... I was bound not to start with what I really think is a good solution.

    Now a "proper" solution.

    template< typename TARGET, typename SOURCE >
    void copyBatch( TARGET & target, SOURCE const& source,
    const char * schema )
    {
    for( size_t index = 1; *schema; ++index )
    {
    switch( *schema )
    {
    case 'I': case 'i':
    target.setInt( index, source.getInt( index ) );
    break;

    case 'S': case 's':
    target.setString( index, source.getString( index ) );
    break;
    case 'F': case 'f':
    target.setFloat( index, source.getFloat( index ) );
    break;
    case 'D': case 'd':
    target.setDate( index, source.getDate( index ) );
    break;
    default:
    assert( !"Unsupported type" );
    }
    target.addBatch();
    }


    Of course I made it a template here because I don't know the types but you don't have to make it one.

    but look at the comment:

    This section should be enhanced at some point
    // using a ResultSetMetadata object, iterating
    // through the column types -aj

    So not even my template solution but a proper object that holds the data was their plan.
  • Vlad Patryshev 2012-11-20 10:25
    "Don't change anything" is what I heard from all kinds of scared managers.
    "We don't have time for unittests" is another motto.

    And no, it's not about "gray-haired" people; half of them are half my age.

    Their scope is short. In half a year, when someone will have to go fix/add functionality/change according to new SOX/SOPA/PIPA laws, the manager will either be in another position or happy to ask for more people to fix the mess.

    Yes, it's low morale.

    I don't think this can be fixed by talking to people. These days everybody knows about stuff; if they don't care - quit.

    (and the captcha is "dolor")
  • ObiWayneKenobi 2012-11-20 10:29
    Noob:
    I really, really hate when the new guy feels the need to point out the obvious and then expects a big pat on the back.

    Yeah - gee - nobody here thought that refactoring messy code would be a good idea. It's not that there isn't a business case or other priorities or anything; we just never thought of it. You must be super good.

    Every place I've ever been at could benefit from...
    * Additional time to refactor
    * Additional testing
    * Additional documentation
    * Additional automation

    It's trivial to walk into a place, spend a day observing, and point out the obvious.


    The reason why is good companies don't need to be told, and don't need to come up with excuses why they can't do basic housekeeping. Anyone clued in and skilled knows that you refactor code mercilessly and avoid ever getting into the situation where your code is shit and you need to rewrite/refactor it, but can't find the time.

    Any place that gets into that situation has a fundamental issue.

    Addendum (2012-11-20 10:40):
    Also, good developers know the value of testing and the benefits of using new/emerging technology to solve problems. One doesn't have to be a bandwagon jumper, but good developers don't get into situations like this, and don't work for companies like this.

    All these places ever get are the desperate (who leave ASAP for greener pastures) and the dregs who are unskilled and unaware of it. Anyone smart sees through these places and don't stick around.
  • TheStandardsAreTooDamnHighParty 2012-11-20 10:40
    You should take a look at the wives of those graybeards....

    I'll bet he'll say:

    "It's a woman okay?" "I know you might prefer one that isn't repulsive, but I need to feed the kids that I created with her ( in error )"
  • lanmind 2012-11-20 10:48
    "Listen, the app works, OK?" started one of the high ranking senior devs


    The obvious WTF is developers locked so hard into a paradigm that they are afraid to change the code. Code smell!
  • Jasper 2012-11-20 10:52
    I've seen code like that before in real applications.

    That's what you get when you program with the JDBC API, instead of using an ORM.
  • JimLahey 2012-11-20 10:54
    It's not too dissimilar at our place to be honest. Developers who can't be bothered to use "go to implementation" in VS telling others who can that "interfaces are too hard" and shouldn't be used.
  • Kushan 2012-11-20 10:56
    I've been landed with a codebase that's at least 16 years old (and probably older). The application has been "upgraded" over the years and currently uses MFC in a VS2008 environment but it has never been "redesigned". New features and fixes has been built on top of other features and bugfixes to the point where the code is nothing short of a complete and utter mess.
    Not only that, but there's all sorts of "Coding 101 DO NOT DO's" littered through it - global variables for nearly everything, goto statements, you name it. The code is spread through about 40 CPP files and when I say "spread through", I mean it - the "main" function jumps around calling functions from all over the place which also call functions from all over the place. Everything is dependant on everything else. Oh and despite using MFC, the main codebase doesn't use a single class for anything - it's straight up bastardised C with a few scatterings of C++ thrown in at random (there's at least 3 different types of string in use, sometimes within the same function).

    It sounds like a nightmare and, sometimes, it is but miraculously - it WORKS. It's fairly stable in that it only tends to break with something new has been added. I could go in and clean it up, but it would take months for just one developer to do (this is a very small company). It would be much better to just rewrite the app from scratch, but as the app has essentially lived an entirely iterative life, there's no design plan, there's very little code documentation and every little cast or "toupper" is important but nobody knows why (either they can't remember or the developer that wrote it is long gone).

    This kind of thing isn't unique, quite a lot of developers are in the same boat. There really is a legitimate reason why some people say "if it isn't broke, don't fix it".
  • Gaza Rullz 2012-11-20 11:00
    Well that's what you're paid for buddy. :)
  • Y_F 2012-11-20 11:04
    //stmtInsertToTarget.setInt(1, 9999);// for testing purposes


    TRWTF are magic numbers for testing!
  • PedanticCurmudgeon 2012-11-20 11:16
    Can we ban anyone who uses the word "whilst"?
  • PedanticCurmudgeon 2012-11-20 11:21
    Chelloveck:
    Heh. I was once told by an older programmer not to use the C ternary operator because "no one understands it".
    If you don't mind registering, we're having a nice flame war in the side bar about this.
  • Jack 2012-11-20 11:23
    Cbuttius:
    By the way, it is a huge issue I have with this site that you cannot see the article whilst you are writing your comment (unless you open another browser window, of course).
    Oh, dear! If only someone would come up with some technology that would let us see, or do, two things at once! This is such a severe impediment to so many kinds of work -- it is a problem that goes far beyond a single web site and in fact should probably be solved at the OS level. Some kind of windowing system would be awesome.

    I should probably go patent that.
  • Cbuttius 2012-11-20 11:40
    Chelloveck:
    Steven Seagal's ponytail:

    Having worked in a "legacy" environment, this was exactly the mindset that I fell into. However, the old dinosaurs would jump all over my code for using newer features of the language because they didn't understand it. I think I still have scars from some of those battles.


    Heh. I was once told by an older programmer not to use the C ternary operator because "no one understands it". You know, the one that goes:


    foo = (bar > 0) ? baz : qux ~ fnf;


    Yeah, there's a brainteaser for you...


    FTFY to handle the FILE_NOT_FOUND case.


  • Cbuttius 2012-11-20 11:41
    Jack:
    Cbuttius:
    By the way, it is a huge issue I have with this site that you cannot see the article whilst you are writing your comment (unless you open another browser window, of course).
    Oh, dear! If only someone would come up with some technology that would let us see, or do, two things at once! This is such a severe impediment to so many kinds of work -- it is a problem that goes far beyond a single web site and in fact should probably be solved at the OS level. Some kind of windowing system would be awesome.

    I should probably go patent that.


    It's called a scrollbar.
  • Gadfly 2012-11-20 11:43
    Ama:
    The code was working, they had other priorities to code first. Where's the WTF?


    The article that I just read was about a guy who told the hiring manager "I hate working inside of sloppy code" and was the hired, only to find that his new job would be "working inside of sloppy code".

    Is it so hard to see the WTF in that? Do you think the hiring manager could have at least warned Michael?
  • Mike 2012-11-20 11:46
    PedanticCurmudgeon:
    Can we ban anyone who uses the word "whilst"?


    Certainly, consider yourself banned!
  • Mr.Bob 2012-11-20 12:03
    Noob:
    I really, really hate when the new guy feels the need to point out the obvious and then expects a big pat on the back.

    Yeah - gee - nobody here thought that refactoring messy code would be a good idea. It's not that there isn't a business case or other priorities or anything; we just never thought of it. You must be super good.

    Every place I've ever been at could benefit from...
    * Additional time to refactor
    * Additional testing
    * Additional documentation
    * Additional automation

    It's trivial to walk into a place, spend a day observing, and point out the obvious.


    Amen to this! I one got some sage advice from a previous coworker who passed on this advice: For the first six months of a new job, Just Shut Up.

    No one likes the new guy coming in and pointing out the obvious, as if all the existing developers are morons. The new guy just doesn't have the feel of the place, or the political capital, to start suggesting changes like that.
  • TheCPUWizard 2012-11-20 12:07
    Some good comments. The approach I require developers to follow:

    1) NO modifications unless they are directly related to the specific task.

    2) Identify ALL opportunities for code improvements.

    3) IF a piece of code requires modification (see #2), then all pending improvements (see #2) shall be reviewed and determined if they are appropriate to "roll into" the current change.

    This reduces the number of accidental bugs, prevents work-creep (similar to scope creep) and focus the effort on code that is actually important.
  • OldCoder 2012-11-20 12:16
    Cbuttius:
    Jack:
    Cbuttius:
    By the way, it is a huge issue I have with this site that you cannot see the article whilst you are writing your comment (unless you open another browser window, of course).
    Oh, dear! If only someone would come up with some technology that would let us see, or do, two things at once! This is such a severe impediment to so many kinds of work -- it is a problem that goes far beyond a single web site and in fact should probably be solved at the OS level. Some kind of windowing system would be awesome.

    I should probably go patent that.


    It's called a scrollbar.


    Unless it's Windows 8.
  • Rhywden 2012-11-20 12:17
    Mike:
    Certainly, consider yourself banned!
    Well, so are you now since you quoted it.
  • ObiWayneKenobi 2012-11-20 12:18
    Mr.Bob:
    Amen to this! I one got some sage advice from a previous coworker who passed on this advice: For the first six months of a new job, Just Shut Up.

    No one likes the new guy coming in and pointing out the obvious, as if all the existing developers are morons. The new guy just doesn't have the feel of the place, or the political capital, to start suggesting changes like that.


    I strongly disagree, only because often the new guy isn't exposed to the myopia that tends to creep into established companies wherein nobody looks to improve and just continue to do things the old way because they don't know better.

    A new developer with experience who is just new to THAT company is usually a godsend as they have a fresh face, a fresh pair of eyes and fresh ideas that aren't mired in stagnation. It's a different story of course if you're hiring a junior or entry-level guy.
  • Will 2012-11-20 12:35
    Only if it actually needs to be maintained. It's not clear this particular code does.
  • My name 2012-11-20 12:40
    Second that!

    In my case, the long-time developer badmouthed me to our boss and weeks later I was on the way out.
  • Some Random Texan 2012-11-20 12:41
    Cbuttius:

    By the way, it is a huge issue I have with this site that you cannot see the article whilst you are writing your comment (unless you open another browser window, of course).


    1. Scroll up.
    2. Click blue clicky "[Expand full text]".
    3. Profit.

    CAPTCHA distineo - Having a destiny equadistance to Neo's.
  • David 2012-11-20 12:47
    In a perfect world, yeah, we would fix ALL of the crappy code, but honestly, we seldom have that luxury.
    My general rule is, if I have to touch the code for any reason, I'll refactor and improve the surrounding code as well. If I'm fixing a bug, or adding a new feature, then they are already going to have to test this piece, so this is an acceptable time to make improvements.
    I typically don't go digging through the code base looking for all of the bad code, just searching for something to improve.
    Rather than "If its not broke, don't fix it." I tend to believe "If its not broke, fix something that IS broke, and refactor the crappy code there while you're at it."
  • jMerliN 2012-11-20 13:02
    letatio:
    What the other developers were saying had some truth to it. They failed in expressing what they meant. Any skilled developer with a few years experience knows that as a rule of thumb, don't fix it if it isn't broken. Re-factoring anything is a sure way to introduce new bugs.

    However, there are sometimes better ways to remedy this. Did the developer propose that they move towards TDD?


    Any skilled developer with a few years experience knows that a general solution to this problem can be trivially tested and proven more reliable than hand-coding a field-by-field copy every time you need one. And the end result is that now you have tested code doing your lifting, and your code becomes incredibly simple to maintain and extend.

    There's some real WTF gold in the comment, though:


    // This section should be enhanced at some point
    // using a ResultSetMetadata object, iterating
    // through the column types -aj


    aj clearly understood how to solve this problem in general, but instead of implementing it, which would've taken 5 minutes + the test, he proceeded to copy/paste 40 lines of get/set and then manually hardcode the types for each.

    But lastly, TRWTF is that there's any code for this at all. What relational database worth using doesn't let you insert the results of a query into a table?

    Captcha: ingenium. This code is not it.
  • ObiWayneKenobi 2012-11-20 13:09
    I saw comments like that at my old job fairly frequently. Our "senior" dev (senior as in tenure, not experience) would often have comments stating "could probably do this better" or "why is this here?" or "don't know what this does". Instead of doing things right he'd instead copy/paste dozens of lines of crap and finish a task immediately, then spend weeks fixing bugs that cropped up because of his half-assed solution.
  • herby 2012-11-20 13:11
    It happened to me once as well. The "login" procedure for the application was intended (originally) for hard copy terminals, and for "security" had a bunch of X's printed where the login stuff was to be typed in. Fast forward to display terminals (or windows with terminal I/O in them) and the overstrikes themselves get overwritten. While this wasn't bad, the prompt was overwritten with the spaces to put in the X's, so there was no prompt.
    Silly me, I tried to "fix" it and have the prompts be the last thing printed so you could at least see them, and everyone raised a hissy fit. The problem was that the "tests" that were run expected the old prompts, and they weren't willing to change anything. My attempts to explain were futile and I reverted the code.

    Silly me for trying to "improve" things to attempt to make the program correspond to the written documentation that had been published years (parts were probably over 30 years old) ago. Don't try that again!
  • Almost a greybeard 2012-11-20 13:14
    I don't see a WTF here with just what has been presented. I see perhaps a junior or inexperienced programmer with disregard to environment, priorities, resources, etc. If I were in that meeting I would have smacked the greybeard's hand though. Presentation is everything.

    As I've progressed over the years I have realized that every bit of code, even a WTF, has extenuating circumstances. And any decent development process would exclude changing working code just to change it. There has to be a compelling reason other than bad code to commit the resources all the way down the line to introduce new code to the system. If you have spare bandwidth, go for it. But every development shop I have been in has always been in a resource deficit. And we've always managed to progressively produce better and better code. But there are always those blocks of code that rogues put into your system just to make you cringe and frustrated that you don't have the time, money, or people to fix (right now).
  • Spewin Coffee 2012-11-20 13:15
    TRWTF is using Java. Even worse? Using Java with databases!
  • Anonymous Bob 2012-11-20 13:31
    jonnyq:
    Ama:
    The code was working, they had other priorities to code first. Where's the WTF?


    I came here to say this.

    If you came in a meeting and said "Hey, let's take this ugly code that works and spend 4 or 5 hours rewriting it so that it's not ugly" I'd respond the same way. Yes, it needs to be done, but 4-5 hours worth of code changes will have to be followed with 9 or 10 hours of testing. And if there is even ONE bug... one little tiny bug in the refactored code, there's going to be bitching from some other department about why we "fixed" something that wasn't broken.

    So, yes, put in a ticket to get it fixed, but that ticket will be a much, much lower priority than all the other things that need to get done.

    Now, on the other hand, if there is even ONE bug with big ugly code, you now have an excuse to make some changes, and in the midst of those changes "sneakily" clean up the surrounding ugly code in the name of bug fixing :)


    Agreed. Especially if your procedures for filing a change request, the meetings to approve the request, assigning and scheduling the request, making the change, demonstrating the fix, code review, testing, documenting, etc. all add up to an unacceptable expense, don't touch it! Of course, in that case TRWTF is the procedure... <sigh>
  • Graybeard 2012-11-20 13:57
    The 'graybeards' did have a point. I would be curious to know how that conversation actually went. It was spun for this story in such a way as to dismiss their point.

    What isn't mentioned is what does recent code look like and is it well tested? I have never worked anywhere (other than a few baby startups) that doesn't have some mission critical legacy junk floating around that is messy, often written in a bygone era and merely ported to the current platform (along with so much other stuff that fixing it wasn't possible at the time of porting.)

    Legacy code can suck sometimes and merciless refactoring for the sake of refactoring often does introduce bugs that cost the business money and the team additional headaches unless it happens to be well tested (but usually well tested code isn't crappy.) I have worked with developers, who while generally competent, refactor needlessly and break things. That causes problems for the business.

    Really as a team they should strive to move forward ensuring that all new code is clean and well tested. Time must be allocated to not fall into the mindset and traps that produced that bad code to begin with. Michael was absolutely right to be annoyed by not doing things right to begin with.

    That doesn't mean it can't ever be fixed. A good rule of thumb is to refactor legacy crap code only when maintenance requires it to be modified anyway, consumed by something new, or perhaps a dependency needs to be modified. Working but messy code is only a problem when it needs to be maintained for something. Lump the work of refactoring and the required testing together with the modification. That is an easier sell to the business.

    I'd prioritize adding good test cases (since I get the impression this isn't well tested) over refactoring since it will help you tremendously when it does come to be time to refactor.
  • C-Derb 2012-11-20 14:01
    herby:
    It happened to me once as well. ...<snip>... My attempts to explain were futile and I reverted the code.
    Maybe I'm just not that passionate about programming (it's a nice paycheck), but over the years I've gotten to the point where if I point out something that seems obvious to change and all I get is resistance, what do I care? I'll leave it as is.

    Not sure where it originated, but this is one of the truest axioms in software development: "There's never time to do it right, but there's always time to do it over again."
  • DildoFaggins 2012-11-20 14:09
    jonnyq:

    Agreed. Especially if your procedures for filing a change request, the meetings to approve the request, assigning and scheduling the request, making the change, demonstrating the fix, code review, testing, documenting, etc. all add up to an unacceptable expense, don't touch it! Of course, in that case TRWTF is the procedure... <sigh>


    Sounds like SOP to me. But remember, before an official change request form can be printed, a 1 year feasibility study must first be conducted.

    Also, change requests must be printed on official greenbar paper, on the official 'change request printer', which is available only 3 months out of the year.

    This is for...security purposes...if you could print a change request form on just ANY paper or printer...then it would introduce unnecessary risk! After all, you can't just go around printing change requests for building hyperspace bypasses on just ANY paper, can you?! The Galactic Hyperspace Planning Council would be most displeased.
  • da Doctah 2012-11-20 14:10
    "Yeah, relax your high standards, man," another graybeard developer advised.

    Who does everyone picture as the "graybeard" when they read this? Socrates? Leonardo da Vinci? Freud?

    'Cuz I'm seeing Tommy Chong.
  • ShallNotPass 2012-11-20 14:16
    da Doctah:
    "Yeah, relax your high standards, man," another graybeard developer advised.

    Who does everyone picture as the "graybeard" when they read this? Socrates? Leonardo da Vinci? Freud?

    'Cuz I'm seeing Tommy Chong.


    I'm thinking more of a rather-stoned George Carlin
  • C-Derb 2012-11-20 14:21
    Chelloveck:

    Heh. I was once told by an older programmer not to use the C ternary operator because "no one understands it". You know, the one that goes:

    foo = (bar > 0) ? baz : qux;

    Yeah, there's a brainteaser for you...
    Just a couple months ago I checked in C# code that used LINQ extension methods only to come in the next day and be told by the "senior" dev that he had rewritten them in LINQ to SQL syntax "so I could understand the code".

    At first I thought if he couldn't understand it, how did he know if he rewrote it correctly? Also, if you are unfamiliar with something, why not learn it? Then I thought, meh, whatever.

    I'm going to keep using what I'm comfortable with, and if he wants to change it, what do I care? Paycheck is the same. Exactly. The. Same.
  • English Man 2012-11-20 14:28
    Remy Porter:
    The real WTF is how often people look at unmaintainable code and say, "Meh, it works, right?"
    No. The time to refactor it is when it needs to be maintained - if it is definitely not buggy you shouldn't fix it because "it's hard to maintain", but wait until that problem manifests.
  • WMB 2012-11-20 14:47
    Kushan:
    It's fairly stable in that it only tends to break with something new has been added.


    Isn't that the very definition of "unmaintainable"?
  • 5urd 2012-11-20 14:48
    This is completely opposite of yesterday's TRWTF which is where the boss actually agrees to a change in the codebase
  • 5urd 2012-11-20 14:50
    English Man:
    Remy Porter:
    The real WTF is how often people look at unmaintainable code and say, "Meh, it works, right?"
    No. The time to refactor it is when it needs to be maintained - if it is definitely not buggy you shouldn't fix it because "it's hard to maintain", but wait until that problem manifests.


    If it makes it so new people can't understand it, them you should fix it ASAP
  • 5urd 2012-11-20 14:50
    English Man:
    Remy Porter:
    The real WTF is how often people look at unmaintainable code and say, "Meh, it works, right?"
    No. The time to refactor it is when it needs to be maintained - if it is definitely not buggy you shouldn't fix it because "it's hard to maintain", but wait until that problem manifests.


    If it makes it so new people can't understand it, them you should fix it ASAP
  • jay 2012-11-20 14:50
    Gadfly:
    Ama:
    The code was working, they had other priorities to code first. Where's the WTF?


    The article that I just read was about a guy who told the hiring manager "I hate working inside of sloppy code" and was the hired, only to find that his new job would be "working inside of sloppy code".

    Is it so hard to see the WTF in that? Do you think the hiring manager could have at least warned Michael?


    If his criterion is that he refuses to take any job where he might be asked to work on code that is poorly written, I think that would considerably narrow his job prospects. If you can find an organization where ALL the code is beautiful and elegant, let me know. Well, they probably wouldn't hire me, because I've occasionally written bad code myself.

    It's one thing to say "I hate working on sloppy code". It's quite another to say "I refuse to work on sloppy code".

    I hate it when a toilet gets clogged. It's ugly and smelly and unpleasant. But this does not me that I refuse to live in any house where the toilets ever get clogged. There is no such house on planet Earth.
  • David 2012-11-20 14:54
    da Doctah:
    "Yeah, relax your high standards, man," another graybeard developer advised.

    Who does everyone picture as the "graybeard" when they read this? Socrates? Leonardo da Vinci? Freud?

    'Cuz I'm seeing Tommy Chong.


    Thems the guys that taught me to 'Fus Ro Dah' harder.
  • havokk 2012-11-20 15:05
    David:
    Rather than "If its not broke, don't fix it." I tend to believe "If its not broke, fix something that IS broke, and refactor the crappy code there while you're at it."

    Nicely put.

    The "if it ain't broke, don't fix it" approach ignores one of the fundamental natures of program code - it is mutable. Most of the time, code you write today will be modified in the years to come, probably by other people. Rewriting bad code is usually a good investment of time. Writing good code in the first place, of course, is almost always a good investment of time.

    As for the ternary operator, would the following be better written code?
    foo = ( (bar > 0) ? baz : qux ) ;
  • jay 2012-11-20 15:05
    David:
    In a perfect world, yeah, we would fix ALL of the crappy code, but honestly, we seldom have that luxury.
    My general rule is, if I have to touch the code for any reason, I'll refactor and improve the surrounding code as well. If I'm fixing a bug, or adding a new feature, then they are already going to have to test this piece, so this is an acceptable time to make improvements.
    I typically don't go digging through the code base looking for all of the bad code, just searching for something to improve.
    Rather than "If its not broke, don't fix it." I tend to believe "If its not broke, fix something that IS broke, and refactor the crappy code there while you're at it."


    Ditto. If the code works, then changing it just to make it cleaner is asking for trouble. If the code works as desired, then by definition there is zero chance of improving its functionality, and a non-zero chance of breaking something. You may make it more maintainable, but if it doesn't need to be maintained, so what? Maybe it will never need to be changed before becoming obsolete and being thrown out, so the effort will be wasted.

    Even if I was sitting around with absolutely nothing to do, I would be reluctant to "fix" code that isn't broken, because if I break something, then my productivity is negative.

    Now when code needs to be changed, and therefore will have to be tested, NOW is the time to do clean-up.
  • ObiWayneKenobi 2012-11-20 15:16
    jay:
    Now when code needs to be changed, and therefore will have to be tested, NOW is the time to do clean-up.


    Exactly. Unfortunately the problem so often arises that when the time comes for the code to be modified, there "isn't time" to do the clean-up because whatever feature was promised yesterday or you just have lazy developers who are afraid to tell the manager "Hey this will take a few extra days so we can do some housekeeping of the code and make future changes like this easier". So you run into ALWAYS putting off the clean-up because there are "other priorities".
  • WhiskeyJack 2012-11-20 15:20
    I often run into legacy code too, and it is often a mess. I won't try to whole-scale fix anything that isn't my direct responsibility, but when I touch a file, I always try to leave it better than when I started. So any new code I write, is 100% according to the company coding standard, and well documented. If I ever have to do band-aid hacks, I will precede them with a big comment saying, essentially, "Yes, this is a hack, here's how it works, and here's how it could be done better if you ever get time".

    I also run the code through the beautifier (formatter) before checking it back in, after confirming with the code review tool that that step only affects whitespace (e.g. NO impact to the code itself or to any CM merges that may follow). Our diff tools are smart enough to know that changes in whitespace don't change anything else.

    I consider coding to be a kind of art form. I want my code to work, but I also want it to look good (in the sense of readability and maintainability).
  • Graybeard 2012-11-20 15:38
    5urd:
    English Man:
    Remy Porter:
    The real WTF is how often people look at unmaintainable code and say, "Meh, it works, right?"
    No. The time to refactor it is when it needs to be maintained - if it is definitely not buggy you shouldn't fix it because "it's hard to maintain", but wait until that problem manifests.


    If it makes it so new people can't understand it, them you should fix it ASAP


    It really depends on what the cost of downtime is. In this case it sounds like they have some potentially costly SLAs to maintain. Some applications are more tolerant of downtime and bugs than others. This should be considered in the 'to refactor or not to refactor' question. There isn't a one size fits all answer. Where I work downtime and the introduction of new bugs is extremely costly to the company and we have legacy stuff that is bad (our recent stuff is not so bad and is well tested.) We comment hard to understand code as we discover what it does, and only refactor when we need to change that code for some other reason.
  • Mike 2012-11-20 16:23
    ... and the answer is "Umm, I think so. God I hope they never ask me what it does."

  • Mike 2012-11-20 16:36
    Sadly sometimes that is what the customer wants. They just want to get the monthly report out today with the new changes that they forgot to ask before the end of the month. If the report spits out but takes 2 hrs to run, or crashes the server immediately afterwards they don't care.

    Sometimes they only want to see their "get report" dialog and let you spend the next month fixing it so it actually works. If you wait till the end of next month to show them something you fail because you didn't meet their emotional needs of seeing jump up and say "yes boss right away boss."
  • Ralph 2012-11-20 16:48
    OldCoder:
    Cbuttius:
    It's called a scrollbar.
    Unless it's Windows 8.
    Gakkkk! You mean Windows 8 gets rid of scroll bars? WTF are they thinking? Don't they know usability experts everywhere agree you can't expect people to learn a new GUI once they've become habituated to their first? That's why we can't get people to move off their Linux desktops to Windows! How is this making it easier??

    Fortunately I haven't been forced to use Windows since XP, so I'm fine. Next you'll be telling me they're planning to fart around with the familiar Office interface for no apparent reason. Thank the gods of open source we have Open/Libre Office so people can have a comfortable, time tested interface.
  • jMerliN 2012-11-20 17:09
    jay:
    David:
    In a perfect world, yeah, we would fix ALL of the crappy code, but honestly, we seldom have that luxury.
    My general rule is, if I have to touch the code for any reason, I'll refactor and improve the surrounding code as well. If I'm fixing a bug, or adding a new feature, then they are already going to have to test this piece, so this is an acceptable time to make improvements.
    I typically don't go digging through the code base looking for all of the bad code, just searching for something to improve.
    Rather than "If its not broke, don't fix it." I tend to believe "If its not broke, fix something that IS broke, and refactor the crappy code there while you're at it."


    Ditto. If the code works, then changing it just to make it cleaner is asking for trouble. If the code works as desired, then by definition there is zero chance of improving its functionality, and a non-zero chance of breaking something. You may make it more maintainable, but if it doesn't need to be maintained, so what? Maybe it will never need to be changed before becoming obsolete and being thrown out, so the effort will be wasted.

    Even if I was sitting around with absolutely nothing to do, I would be reluctant to "fix" code that isn't broken, because if I break something, then my productivity is negative.

    Now when code needs to be changed, and therefore will have to be tested, NOW is the time to do clean-up.


    Productivity isn't measured in functionality and bugs alone. It's also measured in time savings. If you spend 2 years implementing N features, and someone else spends 3 months developing a library but 0 features, then implements those N features in 1 week, they're many times more productive than you. It's unlikely their solution will have 0 bugs, as it is unlikely yours is to have 0 bugs, but what's almost certain is that if they approached solving common problems in a central, maintainable, and clean way, their code can be more easily tested. More importantly, given that it took a week to implement those N features, adding more in the future or changing them is trivial.

    Negative productivity, then, isn't just introducing bugs, it's making future work with the codebase more expensive than it should be, as well. A very common idiom fits this situation perfectly is "penny wise but pound foolish". A bug that takes 30 seconds to fix is nothing compared to perpetuating a design flaw that requires people waste hundreds or thousands of hours debugging, hacking, or just maneuvering around due to an unnecessarily massive/verbose codebase.
  • Carl 2012-11-20 17:13
    Ralph:
    you can't expect people to learn a new GUI
    I had one elderly luser who called me at least twice a week to ask how to track changes. (Tools, Track Changes.) She could even remember the right words: "track changes". Just no idea how to find it.

    Based on her other support requests ("I can't print" means she accidentally dragged the icon of her favorite document to a slightly different location on her desktop, and now, can't find it to open it) I'm pretty sure that she couldn't get out of a burning building if somebody moved the doorknob two inches.

    I had to wait for her to retire before I could upgrade her system off of Windows XP Service Pack 1. You don't know how badly I wanted to install Icon Fright late some evening. (It makes icons flee the mouse pointer.) She probably would have had a heart attack.
  • Buffoon 2012-11-20 17:23
    ObiWayneKenobi:
    jay:
    Now when code needs to be changed, and therefore will have to be tested, NOW is the time to do clean-up.


    Exactly. Unfortunately the problem so often arises that when the time comes for the code to be modified, there "isn't time" to do the clean-up because whatever feature was promised yesterday or you just have lazy developers who are afraid to tell the manager "Hey this will take a few extra days so we can do some housekeeping of the code and make future changes like this easier". So you run into ALWAYS putting off the clean-up because there are "other priorities".


    I learned very early that you should not separate the cleanup and the update of the code. They are one and the same, and your estimate should not be "20h cleanup, 2h update". It should be "22h update". You wont even be lying, since fubared code tends to be unneccesary hard and slow work, so just bolting a new gadget onto the ugly is sure to be brittle and break in interresting ways making a 2h update in reality be 22h anyway, but leave the code a bit uglier instead...
  • :) 2012-11-20 17:46
    this should be featured!
  • Friedrice the Great 2012-11-20 18:06
    C-Derb:
    herby:
    It happened to me once as well. ...<snip>... My attempts to explain were futile and I reverted the code.
    Maybe I'm just not that passionate about programming (it's a nice paycheck), but over the years I've gotten to the point where if I point out something that seems obvious to change and all I get is resistance, what do I care? I'll leave it as is.

    Not sure where it originated, but this is one of the truest axioms in software development: "There's never time to do it right, but there's always time to do it over again."

    "There's never time to do it right, but there's always time to fix the bugs caused by not doing it right in the first place."
  • Anonymous bastard 2012-11-20 19:58
    "Wait what?! You think i will apply emergency patch at 2AM, fuck this!" *walk out*
  • Wawif? 2012-11-20 20:12
    Cbuttius:
    Ok, we don't know the language for certain but it could be C++. Let's try a macro. We'll need to use token pasting (##) to paste Int String or Float to the end.

    Let's get rid of the counting by introducing a number that gets incremented. For the purpose of sequence points we should increment in a separate statement from the main one.


    #define STMT_INSERT_FROM_RSSOURCE(type,var) \
    stmtInsertToTarget.set##type(var, rsSource.get##type(var)); \
    ++var

    then in our code

    while( rsSource.next() ) {
    int field = 1;
    STMT_INSERT_FROM_RESOURCE(Int,field);
    STMT_INSERT_FROM_RESOURCE(Int,field);
    STMT_INSERT_FROM_RESOURCE(String,field);
    // ...
    stmtInsertToTarget.addBatch();
    }


    Ok. Of course I started with a solution I don't like... I was bound not to start with what I really think is a good solution.

    Now a "proper" solution.

    template< typename TARGET, typename SOURCE >
    void copyBatch( TARGET & target, SOURCE const& source,
    const char * schema )
    {
    for( size_t index = 1; *schema; ++index )
    {
    switch( *schema )
    {
    case 'I': case 'i':
    target.setInt( index, source.getInt( index ) );
    break;

    case 'S': case 's':
    target.setString( index, source.getString( index ) );
    break;
    case 'F': case 'f':
    target.setFloat( index, source.getFloat( index ) );
    break;
    case 'D': case 'd':
    target.setDate( index, source.getDate( index ) );
    break;
    default:
    assert( !"Unsupported type" );
    }
    target.addBatch();
    }


    Of course I made it a template here because I don't know the types but you don't have to make it one.

    but look at the comment:

    This section should be enhanced at some point
    // using a ResultSetMetadata object, iterating
    // through the column types -aj

    So not even my template solution but a proper object that holds the data was their plan.


    orly? with macros... burn in hell!
  • Denorman Diamond 2012-11-20 20:25
    jay:
    Gadfly:
    The article that I just read was about a guy who told the hiring manager "I hate working inside of sloppy code" and was the hired, only to find that his new job would be "working inside of sloppy code".
    It's one thing to say "I hate working on sloppy code". It's quite another to say "I refuse to work on sloppy code".

    I hate it when a toilet gets clogged. It's ugly and smelly and unpleasant. But this does not me that I refuse to live in any house where the toilets ever get clogged.
    +1. Too bad you proceeded to fuck it up:
    jay:
    There is no such house on planet Earth.
    You have a lot to learn about planet Earth. If you have a toilet that just needs a push or pull to flush it, that doesn't put you in the 1% but it it puts you in around the top 30%. There are a ton of toilets where you pour water in yourself to flush them, there are a ton that are just pits in the ground, and there are another ton that are almost as bad as some of the code I've worked on.
  • gnasher729 2012-11-20 20:33
    Anonymous bastard:
    "Wait what?! You think i will apply emergency patch at 2AM, fuck this!" *walk out*


    a. You think I will be there at 2am to apply an emergency bug fix?
    b. You think if I was there at 2am I would be in any shape to apply an emergency bug fix that doesn't cause more problems than the fix is worth?
  • Norman Diamond 2012-11-20 20:34
    WhiskeyJack:
    Our diff tools are smart enough to know that changes in whitespace don't change anything else.
    k=i+++j;
    
    k = i + ++j;

    C used to have worse stuff.
    The -= operator was originally =-
    Other assignment operators were like that too but
    they didn't do as much damage.

  • Soviut 2012-11-20 20:53
    Ama:
    The code was working, they had other priorities to code first. Where's the WTF?


    Because the original author even realized it was sloppy and should be refactored. It also sounds like they would NEVER have time for a refactor because they'd never consider it a priority, even if maintaining old messes took more time.
  • Stu 2012-11-20 21:17
    PedanticCurmudgeon:
    Can we ban anyone who uses the word "whilst"?


    Only if we ban everyone who isn't American. Just because a word is not in common use in American English doesn't mean it isn't in common use in other locales.

    More importantly, can we ban anyone who says "Let's see if we can't do X"? That would get rid of all you daft Americans, instead.
  • Darren 2012-11-20 23:16
    He left his job because of that? I think his standards were too high.
  • Trasvi 2012-11-21 02:32
    Why all the hate against this WTF?
    This entire website is about making fun of terrible code, people or procedures.
    This code qualifies for the WTF. But instead of actually pointing out that fact to his colleagues, you think the programmer should have just ridiculed the code online without actually attempting to better the organisation?

    TRWTF is not supporting his actions. Bravo to Michael.
  • Norman Diamond 2012-11-21 03:06
    Refactoring prime numbers is hard.
  • Watson 2012-11-21 03:27
    ObiWayneKenobi:
    This story reminds me of two things:

    1) In July I was let go from a job I had been at for around 2 years because I, like Michael in the story, constantly pushed for us to refactor our crufty legacy code. Our application was a public facing website that received several thousand hits per day, and often would crash 4-5 times a day on average. We actually had three developers leave in three weeks because our ideas were shot down. I was the "last man standing" and got blindsided after buying into the lies I was being fed about fixing things and being promoted to lead.

    2) A week after I left, I heard through the grapevine that they hired someone who took one look at the code and quit, saying he expected them to have better standards. I think he was there a day, if that.


    Those reminded me of why I left a place after a couple of years a couple of years ago. Since it was a public-facing website, and I wanted to gauge how it would look on my resume, I've ended up watching the slow-motion trainwreck play out as bug was followed by crash was followed by "offline for servicing" notice was followed by feature removal (which triggered a new rash of bugs). As of a couple of months ago the site has been totally unresponsive. I think maybe I should drive by the offices sometime and see if they're still occupied.
  • Pinaki 2012-11-21 03:32
    LOL. What a coincidence. I also had the experience of working in a company like this. The company invented their own proprietary framework that mimicked Entity Framework 4.0 but using only Arrays. No generics since they wanted the whole framework to be .Net 1.1 compatible!!!
  • Watson 2012-11-21 03:50
    ObiWayneKenobi:
    jay:
    Now when code needs to be changed, and therefore will have to be tested, NOW is the time to do clean-up.


    Exactly. Unfortunately the problem so often arises that when the time comes for the code to be modified, there "isn't time" to do the clean-up because whatever feature was promised yesterday or you just have lazy developers who are afraid to tell the manager "Hey this will take a few extra days so we can do some housekeeping of the code and make future changes like this easier". So you run into ALWAYS putting off the clean-up because there are "other priorities".


    A problem is that such clean-ups only apply to specific bits of code at the time they need maintaining. An effective clean-up may involve changes elsewhere to, well, refactor common code.

    Otherwise, similar stretches of the code end up getting written differently (maybe they started out as conceptually distinct, or one was written by someone unaware of the other, or it would have Taken Too Long to alter the original code to handle the new case). You end up with three or four implementations of what seem to be the same thing - but not quite - and ending up with a lot of glue to go back and forth between them and/or a lot of duplicated functionality.
  • A Ferengi 2012-11-21 03:53
    The 31st rule of Quick Fixing states: "High standards and an empty wallet is worth the wallet."
  • notme 2012-11-21 04:41
    Before? I'm writing something like that right now. The tables were created a year ago in firebird, then moved to postgre (when fb couldn't take the load anymore). Of course normalization looks like "create separate table for data from each device". Deadline is in about 3 weeks and no one has time to make things properly. This is how shit happens.

    Captcha: inhibeo (propero standardo)
  • notme 2012-11-21 04:45
    On the upside, I've done such thing in previous job and there was always some other fire to put out. Now my boss says "never again such lousy project". After everything works there will be time for refactoring and this time the code has to be made properly. Probably there will be complete rewrite in some other language.
  • Brendan 2012-11-21 04:47
    C-Derb:
    Just a couple months ago I checked in C# code that used LINQ extension methods only to come in the next day and be told by the "senior" dev that he had rewritten them in LINQ to SQL syntax "so I could understand the code".

    At first I thought if he couldn't understand it, how did he know if he rewrote it correctly? Also, if you are unfamiliar with something, why not learn it?


    When considering the advantages and disadvantages of adopting "new", it's amazing how many people are too retarded to consider training costs.

    Imagine if you work in a team of 20 people, and some butt-head goes and adds LINQ. Now 19 other people need to waste a day each learning LINQ. Let's say (for the sake of round numbers) that a developer costs $100 per day. That butt-head just cost $1900 for a start.

    Of course when someone "learns" something in 1 day they're never an expert (they start with zero experience), which means there's ongoing confusion and mistakes that would probably double the initial cost. This means butt-head actually cost $3800.

    However; that assumes that nobody is ever replaced. Maybe over then next 5 years 8 different people will be hired and will have to waste time learning LINQ (at a further cost of $200 each, or $1600). That brings us to a very rough total $5400 caused by our beloved butt-head.

    Total cost of staying with the existing SQL that everyone knows would've been $0. The senior developer maybe spent 30 minutes to fix butt-heads stupidity. The senior developer is smart. He spent about $6 worth of time to avoid $5400 of costs.
  • Cbuttius 2012-11-21 05:10
    David:
    In a perfect world, yeah, we would fix ALL of the crappy code, but honestly, we seldom have that luxury.
    My general rule is, if I have to touch the code for any reason, I'll refactor and improve the surrounding code as well. If I'm fixing a bug, or adding a new feature, then they are already going to have to test this piece, so this is an acceptable time to make improvements.
    I typically don't go digging through the code base looking for all of the bad code, just searching for something to improve.
    Rather than "If its not broke, don't fix it." I tend to believe "If its not broke, fix something that IS broke, and refactor the crappy code there while you're at it."


    It sounds like a nice way to approach things, but my experience has found the contrary.

    Remember we all work in version controlled systems.

    It is best that each change you make is just one single issue. A refactor should be just a refactor, a bug fix should be just a bug fix.

    If you have to rollback your refactor because you made a mistake, you really don't want to rollback the bug fix at the same time, reintroducing the bug.

    Fix the bug. Check in. Refactor. Check in again.
  • Cbuttius 2012-11-21 05:12
    Some Random Texan:
    Cbuttius:

    By the way, it is a huge issue I have with this site that you cannot see the article whilst you are writing your comment (unless you open another browser window, of course).


    1. Scroll up.
    2. Click blue clicky "[Expand full text]".
    3. Profit.

    CAPTCHA distineo - Having a destiny equadistance to Neo's.


    When I am actually typing a comment, whether it is a new one, or a reply to yours, there is no "[Expand full text]" visible. Nor any other comments other than the one I am replying it.

    If I want that I have to right click and "Open in new window".
  • pencilcase 2012-11-21 05:41
    Brendan:
    C-Derb:
    Just a couple months ago I checked in C# code that used LINQ extension methods only to come in the next day and be told by the "senior" dev that he had rewritten them in LINQ to SQL syntax "so I could understand the code".

    At first I thought if he couldn't understand it, how did he know if he rewrote it correctly? Also, if you are unfamiliar with something, why not learn it?


    When considering the advantages and disadvantages of adopting "new", it's amazing how many people are too retarded to consider training costs.

    Imagine if you work in a team of 20 people, and some butt-head goes and adds LINQ. Now 19 other people need to waste a day each learning LINQ. Let's say (for the sake of round numbers) that a developer costs $100 per day. That butt-head just cost $1900 for a start.

    Of course when someone "learns" something in 1 day they're never an expert (they start with zero experience), which means there's ongoing confusion and mistakes that would probably double the initial cost. This means butt-head actually cost $3800.

    However; that assumes that nobody is ever replaced. Maybe over then next 5 years 8 different people will be hired and will have to waste time learning LINQ (at a further cost of $200 each, or $1600). That brings us to a very rough total $5400 caused by our beloved butt-head.

    Total cost of staying with the existing SQL that everyone knows would've been $0. The senior developer maybe spent 30 minutes to fix butt-heads stupidity. The senior developer is smart. He spent about $6 worth of time to avoid $5400 of costs.

    +1
  • Brian 2012-11-21 07:34
    I couldn't agree with you more! Don't try to be the hero, cus you might wind up looking like the asshole. If you REALLY want to obliterate the bad code, you have to rewrite in your SPARE time. I'm a stickler for writing clear, concise code, but not everyone has that knack.
  • Herr Otto Flick 2012-11-21 07:40
    TRWTF is stupid junior dev who thinks that being a programmer is about excellence and awesomeness. It's not, it's about providing working solutions for minimal costs and as few bugs as possible.

    He doesn't like this code because it is inelegant. His solution is to rewrite it all. Fuck off.

    Working for a typical corporate is about getting as much done in the amount of time you have, which is 50% of the time needed. This doesn't matter, since (and this is the bit WTF-jr in the story doesn't get) the software is not the product, it is something that allows you to deliver the product.

    Some of the people on this site get it. The others don't work in corporate environments, they work for software houses - where the software is the product.

    Think of corporate IT as a factory production line. The device that sticks the labels on the bottles doesn't do it quite right, the labels go on at 5° angle. It still works, people will still buy the product, do we spend a bunch of money fixing the labeller, or do we finish the shrinkwrap machine so we can ship some product?

    Note that I'm not saying that corporate IT cannot produce excellent code. That is your challenge, provide unit tests for your code, deliver great code. You just don't waste time fixing code that don't need fixing, just so you get the warm'n'fuzzies.
  • the beholder 2012-11-21 08:56
    Cbuttius:
    When I am actually typing a comment, whether it is a new one, or a reply to yours, there is no "[Expand full text]" visible. Nor any other comments other than the one I am replying it.

    If I want that I have to right click and "Open in new window".
    Right, but there is an easy way to deal with that: just access TheDailyWTF on your tablet/smartphone. Sure you won't get to copy on a device and paste on another, but we can't have everything, now can we?

    OR

    you could stop whining about the need to use one tab for the article, another to comment. What, does your computer only have 512 MB of RAM? Or maybe you're afraid you'll run out of WHNDs?
  • Dave Insurgent 2012-11-21 09:49
    Brendan:
    Total cost of staying with the existing SQL that everyone knows would've been $0. The senior developer maybe spent 30 minutes to fix butt-heads stupidity. The senior developer is smart. He spent about $6 worth of time to avoid $5400 of costs.


    Ah yes, the good ol' "let me show you what you didn't consider using an example that doesn't consider everything" argument.

    You pay no mind, at all, to the productivity improved by acquiring new skills. By your one-sided rationale, no one would ever undertake any kind of automation, optimization or training because it all counts as cost up front. Where's the return factor? The entire reason software developers exist is because they're a ROI after an up-front (or even ongoing) cost.

    You also seem to think that the company should expect to lose productivity just because their developers don't know LINQ. That's obviously not true - being a professional means constantly learning and that happens over and above the hours you spend working. That's how it is for doctors, how it is for lawyers, that's how it is engineers and you-name-it. If you happen, and I think software development is one of those things, to be able to learn/improve while doing the job that's awesome, but if you think you can be a continually relevant and employable professional based only one what you pick up while on the job, you're kidding yourself. Robert Martin says 20 hours a week, but I think that's a bit steep especially with a family. At least 5, more preferably 10, hours a week should be spent on learning stuff not directly related to what you NEED to do your job.

    What does that mean? It means that when it comes time that someone wants to use LINQ in the project, just about everybody on the fucking team that works using C# should know what LINQ is. There's admittedly a gray area when something is an emergent technology or feature compared to when it's been around for a while - but *that* is the argument about putting it in to production. It's the fact that it's leading edge that should make you uncomfortable about throwing it in to a product of any critical nature, not the fact that oh, boy, doofus developer goes home every night and doesn't ever learn a damn thing.

    Also, my company gives everyone a yearly budget for training, and I think most decent software companies do - and its a use-it-or-lose-it type deal, so there is an incentive to at least learn something new every year. That, of course, is in addition to at least one book a month I read, as well as trying new languages and frameworks at home to make stuff that I have no plans to do anything with but throw away.
  • Code Master 2012-11-21 09:54
    Jack:
    Cbuttius:
    By the way, it is a huge issue I have with this site that you cannot see the article whilst you are writing your comment (unless you open another browser window, of course).
    Oh, dear! If only someone would come up with some technology that would let us see, or do, two things at once! This is such a severe impediment to so many kinds of work -- it is a problem that goes far beyond a single web site and in fact should probably be solved at the OS level. Some kind of windowing system would be awesome.

    I should probably go patent that.


    This is not how things are heading. Have your tried using iOS or Modern UI on Windows 8. Full screen apps.
  • ObiWayneKenobi 2012-11-21 10:20
    Dave Insurgent:
    Brendan:
    Total cost of staying with the existing SQL that everyone knows would've been $0. The senior developer maybe spent 30 minutes to fix butt-heads stupidity. The senior developer is smart. He spent about $6 worth of time to avoid $5400 of costs.


    Ah yes, the good ol' "let me show you what you didn't consider using an example that doesn't consider everything" argument.

    You pay no mind, at all, to the productivity improved by acquiring new skills. By your one-sided rationale, no one would ever undertake any kind of automation, optimization or training because it all counts as cost up front. Where's the return factor? The entire reason software developers exist is because they're a ROI after an up-front (or even ongoing) cost.

    You also seem to think that the company should expect to lose productivity just because their developers don't know LINQ. That's obviously not true - being a professional means constantly learning and that happens over and above the hours you spend working. That's how it is for doctors, how it is for lawyers, that's how it is engineers and you-name-it. If you happen, and I think software development is one of those things, to be able to learn/improve while doing the job that's awesome, but if you think you can be a continually relevant and employable professional based only one what you pick up while on the job, you're kidding yourself. Robert Martin says 20 hours a week, but I think that's a bit steep especially with a family. At least 5, more preferably 10, hours a week should be spent on learning stuff not directly related to what you NEED to do your job.

    What does that mean? It means that when it comes time that someone wants to use LINQ in the project, just about everybody on the fucking team that works using C# should know what LINQ is. There's admittedly a gray area when something is an emergent technology or feature compared to when it's been around for a while - but *that* is the argument about putting it in to production. It's the fact that it's leading edge that should make you uncomfortable about throwing it in to a product of any critical nature, not the fact that oh, boy, doofus developer goes home every night and doesn't ever learn a damn thing.

    Also, my company gives everyone a yearly budget for training, and I think most decent software companies do - and its a use-it-or-lose-it type deal, so there is an incentive to at least learn something new every year. That, of course, is in addition to at least one book a month I read, as well as trying new languages and frameworks at home to make stuff that I have no plans to do anything with but throw away.


    This this THIS. If you are a professional developer you should at least be FAMILIAR with emerging technology in your area of specialty. You don't have to be all evangelical and wanting to rewrite everything in the latest and greatest fad, but if you give a "deer in the headlights" look when something new is mentioned and have zero clue what it is or what use it could be, you aren't a professional.

    I work(ed) primarily in C#/ASP.NET so let's use that as an example. If you are a .NET web developer and you don't have the foggiest idea what ASP.NET MVC is, or Entity Framework or LINQ or anything like that, there's a problem; I would go so far as to say that any developer who isn't familiar with the available open source projects in their space (e.g. NHibernate) has a fundamental issue as well. Now, nobody is saying you have to have a dozen home projects to learn MVC, or try to shoehorn every project into using MVC/NHibernate/library-du-jour, but if a developer on your team (whether they've been there one week or 10 years) suggests that a new project could benefit from being done in MVC, the real problem is a developer (senior, junior or otherwise) who is all like "What's this MVC thing? I've never heard of it. Why can't we just use WebForms?" without a second thought or any consideration or discussion.

    Maybe MVC isn't the best choice for that particular project; maybe it's a "thick" web app that would benefit from the WebForms model, but it shouldn't just be "Oh we'll just do the same thing we've done for the past five years" on every project either. This field advances, and good developers advance with it by at least having some cursory knowledge of new trends (whether or not they use it, the point is to know at least a tiny bit about it so you could, in theory, expand on that knowledge for a project).

    I maintain the notion that GOOD companies operate like this. Good companies don't reprimand or fire people who recommend better ways of doing things; instead, they at least consider the possibility. Good companies understand that if you bring in a developer with let's say 5 years of experience, you shouldn't dismiss anything he says because he's the "new guy", since he's not a newbie just new to YOUR company, and could provide some insights that you didn't consider. GOOD companies encourage evolving with technology, not doing things exactly the same way the past 5+ years, without a care to advances. Good companies want independent thinkers who can provide insight/suggestions to improve their operations, while bad companies like the one in the article want mindless drones.
  • Neil 2012-11-21 10:30
    Firefox is now on a six-week rapid release schedule, and it doesn't seem to prevent them from doing refactoring (although there were some really big refactorings under the old schedule).
  • ObiWayneKenobi 2012-11-21 10:43
    Neil:
    Firefox is now on a six-week rapid release schedule, and it doesn't seem to prevent them from doing refactoring (although there were some really big refactorings under the old schedule).


    Again, it kind of goes back to company/team mentality. A good team with competent developers usually uses principles and practices that encourage constant refactoring and enough abstractions, backed up by unit tests, to keep the code relatively clean or else keep the smelly hacks isolated where they can be addressed later without polluting the rest of the code.

    On the contrary a poor team always focuses on "tasks" and getting things done as quick as possible without concern, the overall notion being that there's always some new feature that precludes routine housekeeping or even just following the Boy Scout Rule while making a change to the code. A developer on this kind of team will, even if changing a module that could use refactoring, make a quick hack and move on to the next task when they should have taken a bit longer to do some cleanup of the code.

    Again, I have seen this behavior firsthand as well as it being showcased in a few articles where a lazy developer will understand that things SHOULD be refactored, but instead of actually doing it will just copy/paste a change or add a hack, close out the task and move on to the next one without any thought.
  • WhiskeyJack 2012-11-21 10:52
    Norman Diamond:

    k=i+++j;
    
    k = i + ++j;



    Heh. Ok, fair enough, but the diff tool would catch that because that's more than a change of whitespace, that's adding whitespace where none was there before.

    Hmm, or would it? I shall have to experiment sometime.
  • Cbuttius 2012-11-21 11:54
    Herr Otto Flick:
    TRWTF is stupid junior dev who thinks that being a programmer is about excellence and awesomeness. It's not, it's about providing working solutions for minimal costs and as few bugs as possible.

    He doesn't like this code because it is inelegant. His solution is to rewrite it all. Fuck off.

    Working for a typical corporate is about getting as much done in the amount of time you have, which is 50% of the time needed. This doesn't matter, since (and this is the bit WTF-jr in the story doesn't get) the software is not the product, it is something that allows you to deliver the product.

    Some of the people on this site get it. The others don't work in corporate environments, they work for software houses - where the software is the product.

    Think of corporate IT as a factory production line. The device that sticks the labels on the bottles doesn't do it quite right, the labels go on at 5° angle. It still works, people will still buy the product, do we spend a bunch of money fixing the labeller, or do we finish the shrinkwrap machine so we can ship some product?

    Note that I'm not saying that corporate IT cannot produce excellent code. That is your challenge, provide unit tests for your code, deliver great code. You just don't waste time fixing code that don't need fixing, just so you get the warm'n'fuzzies.


    No it's about being given responsibility and need-to-do tasks and ensure they get done in the way you see fit.

    Yes you need tests and bug / issue databases but then it goes too far when every refactoring or code improvement change has to be justified by tracking it against such databases.

    Developers are paid a salary, not paid by line of code changed, and therefore they don't have to justify them based on that they are being paid for these changes.

    Developers will be more efficient when they are in charge of the code they are maintaining and not too restricted. Source control and isolating things into proper components allows such changes to be made in a safe and tested environment.

    The environment of "we don't touch it unless it fixes an issue" is the WTF.
  • Jack 27 2012-11-21 12:02
    Michael: So if you don't want to change it, why do you have a comment reminding everyone that it needs to be changed?

    Senior Dev: Don't pay attention to the comments. The code works just fine.

    Michael: Why not remove the comment then?

    Senior Dev: NO! Too risky. If it ain't broke, don't fix it!
  • Jack 27 2012-11-21 12:11
    WhiskeyJack:
    Norman Diamond:

    k=i+++j;
    
    k = i + ++j;



    Heh. Ok, fair enough, but the diff tool would catch that because that's more than a change of whitespace, that's adding whitespace where none was there before.

    Hmm, or would it? I shall have to experiment sometime.


    I was surprised to find that Beyond Compare doesn't think there are any important differences between
    k = i++ + j;
    and
    k = i + ++j;
    Maybe you could edit the BC's C grammar to make it understand, if you really cared.
  • barf 4 eva 2012-11-21 19:03
    Whatever... Sometimes you are too freaking busy to be redeveloping code that management can't "capitalize" on... As much as I agree with the OP, the old graybeards are right as well when it comes to certain corporate environments. Hope the OP finds that job that DOES have the time to invest in a good clean solid no-slop approach!!! I shall, of course, be envious.

  • Asteroid 2012-11-21 23:43
    I work on-and-off on a system that started under 286 Xenix.

    I'm happy if the dinosaurs just write ANSI-style function definitions instead of K&R, and can remember that the stack is big and the heap exists.

    I wish I was kidding. God, do I wish I was kidding. Just figuring out the hundred global variables is enough to drive you crazy.
  • Herr Otto Flick 2012-11-22 07:18
    Neil:
    Firefox is now on a six-week rapid release schedule, and it doesn't seem to prevent them from doing refactoring (although there were some really big refactorings under the old schedule).


    Because 'producing a better version of firefox' is the only goal of people working on firefox, it behoves them to act like this. Same goes for most other open source software, and anything where software is the product.

    This is why reading things like JoelOnSoftware is good and bad. Joel used to work for MS, making software products. He now works for himself, making software products. He has to make his software great, and so he can bang on about how to make wonderful software - but his environment is not the corporate.

    In a corporate environment, we are not trying to build the best "Phone Billing Manager Export" program in existence, we just need to export the right data at the right times. Yes, the code could be written better, but doing so delays us from making the now essential changes to salesforce, and doesn't net the business anything, apart from IT's warm'n'fuzzies.

    In corporate, IT isn't the product, it's the solution. Some people in IT forget that, like the junior dev in this story. They think that since IT is so important to them, IT is the product. They need to get a clue.
  • Herr Otto Flick 2012-11-22 07:20
    Cbuttius:

    The environment of "we don't touch it unless it fixes an issue" is the WTF.


    We don't touch it unless the business tells us that it is important. It works, it does what the business wants it to do, it's a little ugly, so you want to stop working on what the business needs, and instead work on what IT wants.

    That's the WTF.
  • ObiWayneKenobi 2012-11-22 07:44
    Herr Otto Flick:
    In corporate, IT isn't the product, it's the solution. Some people in IT forget that, like the junior dev in this story. They think that since IT is so important to them, IT is the product. They need to get a clue.


    No, the business needs to get a clue that having clean code facilitates easier changes and additions down the road. That's always the problem in Corporate IT: You're too focused on "exporting the right data at the right time" that a year later when you need to export another type of data, or the data you need changes, it introduces a ton of other bugs because you hacked some shit together the first time instead of using real design patterns and software engineering principles.

    Constant refactoring, heavy design patterns, TDD/testing and the like aren't just the domain of software companies and OSS users, they should be the norm EVERYWHERE because what they do is focus on maintainable, scalable and extensible code, so later on when the business needs change (and this is doubly so in a corp environment where things are always changing, sometimes slightly and sometimes drastic 180 we're changing our business model changes), the team can respond quickly without introducing new bugs or adding new kludgy hacks to the system.
  • Leonardo Herrera 2012-11-22 09:35
    It's not "meh." Revenue generating code vs an ego trip is a lost battle already.
  • Foo 2012-11-22 09:35
    peter:
    Ama:
    The code was working, they had other priorities to code first. Where's the WTF?


    The problem with this approach...

    On top of that, ...

    Don't ask me how I know this.

    captcha: abigo: a big null?


    >Don't ask me how I know this.

    OK, I'ma gonna ask you: "Why havn't you posted this to TDWTF yet?"
  • Cbuttius 2012-11-22 12:01
    Because so many software development teams are badly managed, and often treat developers with so little disregard that they just want to leave.

    Firstly, the best size for a development team is 2. Of course if your software is a very large scale, then have 2 teams of 2.

    You then have project managers who discuss the "whats" not the "hows".

    Issue tracking databases are intended to be there for project managers and testers to raise issues.

    For refactoring exercises that are going to take significant time, you should clear with your project manager its benefits and how it will not interfere with getting delivery on time, or why delivery needs to be delayed for the better purpose.

    For small changes that will take a relatively insignificant time to implement (like this one) you should not require such permission.

    Of course, just because I'm giving a general licence to change the code as you see fit does not mean you do not have to adhere to standards: use source control, ensure your code is properly tested, and it should also be properly documented.

    With the particular example, my response to the developer that "yes, we have had plans to change that, as denoted in the comments, but we have not yet had time as we have to ensure delivery is done on time, and we have had actual bugs to fix which are higher priority. Also we need to ensure any change if adequately tested. Once we get ahead of schedule we can work on it. In the meantime, if you're stuck for something to do (i.e. you are blocked on any of your own issues) you can get down to writing some tests for the change you wish to implement".

  • Jo 2012-11-22 12:42
    TRWTF is that they're considering to use ResultSetMetaData just to write type-agnostic code.
    Using getObject and setObject would have worked just as well, and with the exactly same amount of type safety - i.e. DB complaining if the types don't match.

    BTW for those still contemplating macros: It's Java, not C++.

    Captcha: verto - "I turn around". Heh.
  • Shawn Solomon 2012-11-22 17:07
    The code itself isn't really *that* horrible. The WTF to me here is Michael. Where what was it? Three weeks into the code he was hoping to use something that scored him points in an interview to score further points with the dev team? Sounds like a guy who has off standards and priorities that can't take criticism.

    Maybe a WTF is also from the interview. They set-up his expectations perhaps that he'd mostly be refactoring code in the beginning?
  • Cbuttius 2012-11-23 03:21
    The macro wasn't a serious suggestion. It would be worse in my opinion than the code that is already there.

    The template was a more genuine possible solution, the point being that this pattern is being used "all over the codebase" and the template makes it reusable.

    Of course if this is Java you would probably have the base object of the input source and the base of the output source and you'd need to set up a schema object, which could be done as an array (but a string doesn't work that well). I would also use enums in the array.

    If you want to write it a line at a time, you might use an enum, but the code as it stands is far better than using column names where it has to look up the name for every record you like.
  • Older and Wiser 2012-11-23 22:56
    Protip for the fresh out of college: Your colleagues are going to be idiots. It will be a feat in itself that they can code at all, let alone code something that is easy to read, understand, or maintain. Quite literally, they will be "code monkeys". If you're reading this and telling yourself "No! mine aren't...!" then guess what? You're one of the code monkeys! Now you know. In a perfect world there will be no political boundaries to juggle, but in the real world you'll be forced to put up with it and do your best to workaround their incompetence. You'll probably have to put up with seeing them being praised for their speediness at times too, while you go unappreciated, despite the invisible costs down the road of having to maintain the garbage. I can sympathize with the OP.
  • Gibbon1 2012-11-24 22:45
    Cbuttius:
    The code looks WTF'y but I challenge the posters here to write the fix.

    You'd ideally want a schema object, that will run through the various possible types.

    Also please show me how this schema adds any improvement, given that you are going to populate it anyway somewhere. Hard-coded?


    Well one improvement is you probably could no longer use grep to investigate the code base. This is important, you want to nip stuff like that in the bud.
  • dork 2012-11-26 12:22
    this is sort of the programmers "chicken vs the egg" ultimate delima! do you spend time knocking out paying projects or all of your time rewriting old code to fit into your personal view of clean and efficient... and as sarcastic as that may sound, it will be a different answer for everybody what "clean and efficient" mean, want proof just read the comments off of any one of the WTFs about how many ways there are to do something. i think when it comes down to it simply for a bug fix, fix it (if time re-factor it), but dont just be changing code to be changing it. i also consider a routine that takes so much time to run due to inefficient code that it starts to negatively impact the customers to be bug as well so i believe all that has to be weighed in not just start rewriting everything, remember KISS (keep it simple stupid) and if it works, leave it a lone are really good practices in today's competitive programming world! my $0.02 for what its worth, and if this is enough to "honk off" this new programmer and get him to move along, he better thicken up his skin because there's way worse crapola out there in our field waiting under every little leaf, blade of grass, class, method, function, etc. this is not a field for the faint of heart i fear!
  • Benjamin Smith 2012-11-26 13:25
    The WTF isn't that refactoring was being delayed, it's the attitude that leaving it be is OK. Code doesn't exist in a vacuum, it exists to make a problem go away.

    The problem with crufty code isn't that it doesn't make a particular problem go away, it's that when the problem changes over time, it's difficult to amend the software to meet the required changes in need. Because of this, you have solution that may be cheap to begin with but becomes increasingly expensive over time.

    Delaying a refactor increases expense over the long term and works somewhat similar to interest on a financial debt.

    See: Technical debt. http://en.wikipedia.org/wiki/Technical_debt

  • ObiWayneKenobi 2012-11-28 07:57
    Benjamin Smith:
    The WTF isn't that refactoring was being delayed, it's the attitude that leaving it be is OK. Code doesn't exist in a vacuum, it exists to make a problem go away.

    The problem with crufty code isn't that it doesn't make a particular problem go away, it's that when the problem changes over time, it's difficult to amend the software to meet the required changes in need. Because of this, you have solution that may be cheap to begin with but becomes increasingly expensive over time.

    Delaying a refactor increases expense over the long term and works somewhat similar to interest on a financial debt.

    See: Technical debt. http://en.wikipedia.org/wiki/Technical_debt



    And if it gets too high the only answer is "technical bankruptcy" i.e. scratch it and start a rewrite.
  • Amy 2012-11-28 15:09
    Amen, brother!
  • Amy 2012-11-28 15:11
    Meep:
    Remy Porter:
    The real WTF is how often people look at unmaintainable code and say, "Meh, it works, right?"


    What you do is realize:

    a. if you break it, you're the fuckup

    b. other people will keep writing more shit code.

    So you conclude that you'll just try to keep your code clean.

    Until people shit all over that, too.



    (ignore the first reply... forgot to quote)

    AMEN Brother!!
  • JM 2012-11-30 06:19
    "Re-factoring anything is a sure way to introduce new bugs. "

    No, it isn't. Seriously, do you code blindly while drinking a gallon of whiskey - or do you not make sure to have unit-tests to prove that any changes haven't broken anything?

    I think way too many grey-beards might be residing here.
  • experienced middle-of-the-night programmer 2012-12-02 10:33
    The developer is proposing replacing code that maps a list of strings/ints into some sort of row structure (and then adds that row), identifying what belongs where by position.

    I am fairly certain that there is no way of rewriting this code without putting this mapping in another place which unless that this same IDENTICAL mapping to row structure is done in multiple places in the code, will result in anyone referring to this mapping needs to both find the code where it is used and the external mapping. Looking in two places is more work than one.

    About the only thing I would have changed in the code is to put a comment identifying the associated column name; I would do this when the mapping is being changed.
  • Tortoise 2012-12-18 23:38
    You should see our PHP codebase.

    An excerpt:
    $html.=(@$_POST["PetName".$i]||@$_POST["PetSpecies".$i]!=="Not specified"||@$_POST["PetBreed".$i]||@$_POST["PetAge".$i]||@$_POST["PetGender".$i]||@$_POST["PetAltered".$i])?'<tr><td>'.((@$_POST["PetName".$i])?htmlspecialchars($_POST["PetName".$i]):'&nbsp;').'</td><td>'.((@$_POST["PetSpecies".$i])?(($_POST["PetSpecies".$i]==="Other")?htmlspecialchars($_POST["PetOther".$i]):$_POST["PetSpecies".$i]):'&nbsp;').'</td><td>'.((@$_POST["PetBreed".$i])?htmlspecialchars($_POST["PetBreed".$i]):'&nbsp;').'</td><td>'.((@isset($_POST["PetAge".$i]))?htmlspecialchars($_POST["PetAge".$i]):'&nbsp;').'</td><td>'.(@isset($_POST["PetGender".$i])?(($_POST["PetGender".$i])?'Male':'Female'):'&nbsp;').'</td><td>'.(@isset($_POST["PetAltered".$i])?(($_POST["PetAltered".$i])?'Yes':'No'):'&nbsp;').'</td></tr>':'';