The Daily WTF: Curious Perversions in Information Technology

ObiWayneKenobi · 2012-11-20 Reply Admin

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.

2012-11-20 Reply Admin

Only if it actually needs to be maintained. It's not clear this particular code does.

2012-11-20 Reply Admin

Second that!

In my case, the long-time developer badmouthed me to our boss and weeks later I was on the way out.

2012-11-20 Reply Admin

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).

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

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

2012-11-20 Reply Admin

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."

2012-11-20 Reply Admin

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 Reply Admin

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 Reply Admin

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!

2012-11-20 Reply Admin

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).

2012-11-20 Reply Admin

TRWTF is using Java. Even worse? Using Java with databases!

2012-11-20 Reply Admin

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>

2012-11-20 Reply Admin

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.

2012-11-20 Reply Admin

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."

2012-11-20 Reply Admin

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 Reply Admin

"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.

2012-11-20 Reply Admin

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

2012-11-20 Reply Admin

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 Reply Admin

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.

2012-11-20 Reply Admin

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"?

2012-11-20 Reply Admin

This is completely opposite of yesterday's TRWTF which is where the boss actually agrees to a change in the codebase

2012-11-20 Reply Admin

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

2012-11-20 Reply Admin

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

2012-11-20 Reply Admin

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.

2012-11-20 Reply Admin

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 Reply Admin

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 ) ;

2012-11-20 Reply Admin

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 Reply Admin

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 Reply Admin

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).

2012-11-20 Reply Admin

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.

2012-11-20 Reply Admin

... and the answer is "Umm, I think so. God I hope they never ask me what it does."

2012-11-20 Reply Admin

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."

2012-11-20 Reply Admin

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.

2012-11-20 Reply Admin

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.

2012-11-20 Reply Admin

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.

2012-11-20 Reply Admin

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 Reply Admin

this should be featured!

2012-11-20 Reply Admin

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."

2012-11-20 Reply Admin

"Wait what?! You think i will apply emergency patch at 2AM, fuck this!" walk out

2012-11-20 Reply Admin

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!

2012-11-20 Reply Admin

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.

2012-11-20 Reply Admin

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?

2012-11-20 Reply Admin

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 Reply Admin

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.

2012-11-20 Reply Admin

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.

2012-11-20 Reply Admin

He left his job because of that? I think his standards were too high.

2012-11-21 Reply Admin

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.

2012-11-21 Reply Admin

Refactoring prime numbers is hard.

Watson · 2012-11-21 Reply Admin

ObiWayneKenobi:
This story reminds me of two things:

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.

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.

2012-11-21 Reply Admin

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 Reply Admin

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.

Your Standards Are Too High

Leave a comment on “Your Standards Are Too High”