The Daily WTF: Curious Perversions in Information Technology

callcopse · 2012-03-07 Reply Admin

Matt Westwood:
Aargle Zymurgy:
Matt Westwood:
Malcolm:
I understand the whole ‘beauty of code’ thing, but there’s also the ‘beauty of productivity’. . If he can knock out code in a hurry, if it works well enough to get the job done, and the client is happy trading solution time for the occasional error, what the hell, it’s still a good deal. . I can understand the whole dim a,b,c,d too. I do the same thing all the time. You start out not knowing how many vars you’re going to need, and you never get around to cleaning up the code once you’ve got something that works well enough for the problem. . I know that in a perfect world, there would be a committee to debate the functionality. There would be flowcharts printed in color on bonded paper. There would be hundreds of pages of documentation that no one would read. There would be meeting after meeting, conference calls, e-mails, and a great deal of face-to-face meetings over lunch at the home office. . But the practical reality is this: the end user doesn’t care if the code is clean. Given a choice between ugly code that works tomorrow and beautiful code that works next year, what do you think they will choose? . And you know what… they’re right.

Beg to differ. If you write it properly in the first place, there's no need for you (or someone like you) to keep having to knock code out in a hurry, because it works neatly just the way the customer wants it.

Incompetent engineers come in two flavours:

a) the sort who bash out shit quickly and hope that's what the customer wanted - but never mind if it's not, because they can quickly bash out some more shit, and

b) the ones who haven't got a clue how to go about coding, so instead of designing something concrete they waste time in creating management reports, planning charts, development meetings, anything but actually committing code to keyboard, in the hope that someone out there will accidentally tell them what to do.

I understand from your own false dichotomy that you've only ever met incompetent engineers.

Oh, there's a place for all the above concepts. I know how to write elegant and efficient code, but on occasion I have to consider the scope of the task at hand. Like every other programmer, I've written hundreds of short, throw-away programs designed to solve one problem one time and there's simply no point even to documentation.

In "The Psychology of Computer Programming" there's a story of the fellow working to get data inputs for a program to be "super-efficient." The professor he was working for was getting very frustrated waiting for the results of the programmer's work... and it was yet another run-once program but the programmer was off obsessing over the input routines.

When I was a young programmer, I got caught in an inter-department war. The battle that I think got me fired was over a sort program. One manager had hired a contractor at exhorbitant hourly rates for a full month to produce the sort program. I mentioned to her and my own manager when we were in a meeting that the program could have been written in an afternoon. She got furious and left. My manager asked me if I was kidding. I said "no" and he got an evil grin and said "do it." So a couple hours later I had a clone of the other progam working (how hard are sort programs, really?) and took it to my manager who then dropped it off on the other manager. I gather there was some shouting involved. The next day she's back with a triumphant look as she shows us her figures. It seems that on a few million records her sort was a few milliseconds faster. I knew how much the contractor was making per hour and I asked, "the company paid him $15,000 [1985 dollars] for that program. Was it really worth it?" Oh, well. Me and my big mouth, but stress of being there nearly put me in the hospital. I could probably write a few WTF stories about that place.

There is no such thing as a "short, throwaway program". It's always going to be: "Matt, where's that program you wrote last month for munging the project file? Can you dig it out and ...?" If you're 1% competent, you'll make sure all your short one-off throwaway programs will be written with the same care as you write your production code - and if you find it impossible to write to production quality as quickly and efficiently as you write shit, then sorry, but you're the one who's shit.

I expect you got fired because of your intolerably complacent, pompous and sneering attitude. Now fuck off back under your stone.

Matt, you're a very angry guy and probably a bit of a twat yourself - that's what I like about you. You put me in mind of my directory of VBS files used to sort out this, that and the other - all so neat and tidy you can grok them in a jiffy (used every quarter or so, so it just makes it easy to re-use them when you need to).

I understand the premature optimisation argument but that is nothing to do with presenting your code acceptably - which you should ideally not even need to think to do.

Why do I always seem to get stuck with the code from the guys that all think it easier to just knock out whatever shite?

joeyadams · 2012-03-07 Reply Admin

Minos:
You make a good point about locale pitfalls in the date literal, but I don't think that was the case here. Your result agrees with mine. 2007-11-04 22:04:34-05 is the same as 2007-11-05 03:04:34+00 and 2007-11-04 19:04:34-08.
You are also correct about the 13 second error (instead of 11). That's what happens when I do math myself instead of making the computer do it.

Whoops, I stand corrected. I was thinking 22:04 was 8:04 PM. We both made off-by-two errors.

2012-03-07 Reply Admin

Is it possible that somebody was coding under the influence of dosequis?

Captcha: acsi -- when ucinod is over-engineering.

2012-03-07 Reply Admin

geoffrey:
GMT Uber Alles!:
geoffrey:
frits:
TRWTF is time zones. All locales should be on universal time.
If everyone using your app is in one time zone, I fail to see a reason to add the complexity of converting to and from some magic universal time.
And what do you do when it gets sold in another timezone?
Your sales team aren't going to turn down a million-dollar contract just because it happens to be in a different timezone. They're going to make that sale, complete with a shipping date of next month and expect you to hit it easily.

Then what happens? Oh yes, you go on a death march trying to find every single place in the code where a date or time is used. You'll miss some places, causing odd bugs that only pop up in the customer's timezone on certain days/times - probably when you're asleep so you end up woken up to fix it "RIGHT NOW".

So you end up at least exhausted if not fired.

For some reason it's US based software that tends to be the worst for timezone issues - a lot caused by communication between machines in different timezones, differences in date formatting and daylight saving time changes.
A wise man once told me that you solve today's problems today, and tomorrow's problems tomorrow. If a salesperson sells to an out-of-timezone client tomorrow, then that's when the organization should worry about any time zone issues. Otherwise they're just wasting cycles they could be putting into other features. Everyone knows that in software sales, there is a bit of vaporware in every sale, so the rep can just "sell the gap," and bake in some time for the dev team to fix any issues. Besides, there are always workarounds if the software can't be upgraded in time.

The saying has merit, but it doesn't apply to time - because Time is already today's problem. Almost everywhere outside the tropics has two timezone changes a year, so you almost certainly need to handle that already.

So you have a choice - piss about trying to handle DST/summer time with a hundred different piecemeal corrections all over the codebase, or do it right to begin with and save yourself that biannual headache, while getting the ability to sell your product in the state next door as a free bonus.

It's so trivial to do it right that it's fundamentally stupid to do it wrong. The rules are really simple: A) Convert to UTC the moment you get the datetime.

This is the only moment you actually know the right format and the timezone. Both could change in a couple of seconds time. B) Convert to local time when displaying the datetime and nowhere else.
Again, this is the only moment you actually know the right format and the current timezone. C) Always process and store datetime in UTC.
Trivial because your program logic isn't seeing anything else by now anyway!

This is also really easy to check up on during whitebox testing: If the date enters into the program without being converted to UTC, or gets displayed without converting to local, then you have a bug. It's much harder to review when you have a situation where sometimes datetimes need converting but other times it doesn't.

Most frameworks have these time conversion functions already implemented that read the system locale or have a config file, so it's easier to do it right in the first place anyway.

Finally, if you find out later on that your timezone convertor has a bug, you only have to fix code instead of code and all data so far. Correcting data is orders of magnitude more complex than correcting algorithm.

The right way is often much easier than the wrong way.

2012-03-07 Reply Admin

L.:
geoffrey:
frits:
TRWTF is time zones. All locales should be on universal time.

If everyone using your app is in one time zone, I fail to see a reason to add the complexity of converting to and from some magic universal time.

There can be only one . time reference for a machine. trying to make that your local piece of crap timezone is retarded. don't do it. it's not simpler, it's just worse.

I spit on your timezone. Phtaph!

Shagen · 2012-03-08 Reply Admin

Yawn:
L.:
geoffrey:
frits:
TRWTF is time zones. All locales should be on universal time.

If everyone using your app is in one time zone, I fail to see a reason to add the complexity of converting to and from some magic universal time.

There can be only one . time reference for a machine. trying to make that your local piece of crap timezone is retarded. don't do it. it's not simpler, it's just worse.
I spit on your timezone. Phtaph!

Really, working with UTC is something most *nix folks are already used to, and to me it makes perfect sense. I live and work in a fairly sparsely populated timezone, and my software services areas outside that timezone. I can't really see any good reason not to use UTC.

2012-03-08 Reply Admin

Shagen:
Yawn:
L.:
geoffrey:
frits:
TRWTF is time zones. All locales should be on universal time.

If everyone using your app is in one time zone, I fail to see a reason to add the complexity of converting to and from some magic universal time.

There can be only one . time reference for a machine. trying to make that your local piece of crap timezone is retarded. don't do it. it's not simpler, it's just worse.
I spit on your timezone. Phtaph!
Really, working with UTC is something most *nix folks are already used to, and to me it makes perfect sense. I live and work in a fairly sparsely populated timezone, and my software services areas outside that timezone. I can't really see any good reason not to use UTC.

I really just don't see the point of UTC. It's been notoriously unreliable since its inception, and I can't have applications in the enterprise bear that kind of risk.

2012-03-09 Reply Admin

anon:
not even starting on the fact that all the variables are Variant...

Good, then I won't have to start on the fact that, since this has been clearly stated to be a Classic ASP application, we're obviously dealing with VBScript, and therefore variables can't be anything but Variant.

2012-03-12 Reply Admin

geoffrey:
Shagen:
Yawn:
L.:
geoffrey:
frits:
TRWTF is time zones. All locales should be on universal time.

If everyone using your app is in one time zone, I fail to see a reason to add the complexity of converting to and from some magic universal time.

There can be only one . time reference for a machine. trying to make that your local piece of crap timezone is retarded. don't do it. it's not simpler, it's just worse.
I spit on your timezone. Phtaph!
Really, working with UTC is something most *nix folks are already used to, and to me it makes perfect sense. I live and work in a fairly sparsely populated timezone, and my software services areas outside that timezone. I can't really see any good reason not to use UTC.

I really just don't see the point of UTC. It's been notoriously unreliable since its inception, and I can't have applications in the enterprise bear that kind of risk.

Thanks geoff, you talking against it was all everyone required to understand how important it was ;) geoff troll best troll !

2012-03-12 Reply Admin

Evan:
geoffrey:
Early binding improves performance, the opposite of what you seem to think.
I suspect that was just a bit of bad wording on Jay's part, especially considering how clearly-worded what he was replying to was.
And these variables were in a very small function. I'm not seeing the need for verbose naming for such a small scope. If you can't look into a 5-line function and determine the use of a particular variable through context alone, then you probably should be in a different line of work.
The question isn't whether you can figure it out, it's a question of how easy it is to.
By putting this expression through Google translate a number of times. You can find out what he meant, but it is certainly less clear than when he wrote it.

(Original: "Just like this sentence I put through Google translate a bunch of times. You can figure out what I meant, but it's definitely less clear than when I typed it." English -> Portuguese -> Spanish -> Norwegian -> English.)

L.:
when you're doing such overly simplistic stuff. there is NO point in having stupidRetardedLongUglyVariableWeiRDcasEName declared.
Because of course the only two options are single-letter names and 43-character, multi-word names.
Unless you think that, say, base and diff or something are "stupid retarded long ugly variable weird-cased names".

You start from the assumption that anyone gives a f* as to what is written in the black box.

The truth is nobody does, it's a low-level tool and the only thing you expect from it is to do what the function /method name says, as efficiently as possible.

NO reason to using long var names.

AND, no reason to use long var names in ANY production code, there's a damn good reasons scripts get minified and code gets compiled.

damn phoolz.

2012-03-12 Reply Admin

Malcolm:
I had a similar experience one time involving surveillance cameras. I was down to the main office for meetings when I heard that they were about to spend $3000 for a video surveillance viewing/recording station. I went out at lunch hour and put one together that cost them a total of $200. . But back to the main point… . Like I said, I’m a big fan of clever coding. I’m in awe of those who can knock out in 5 lines what it takes mere mortals like me 30 lines to do. . But in the painfully real (and fast paced) world I work in (the restaurant industry), there is no next week. I’ll get a call at 8pm telling me something that needs to be deployed in 120 locations by 8AM the following morning. That’s just the way the restaurant business works. And that sort of thing happens all the time. . And the reason for needing the code has nothing to do with problems in prior code. It’s just the nature of that fast-paced beast. For example: You find out at 8pm that your supplier is changing case sizes on a major food item for deliveries that are arriving tonight. Stuff like that. No one is to blame. Nothing could have been done to prevent the problem. It’s just a sh*t sandwich that‘s your job to eat. . And in a case like that, the client will never see the code. It will be run exactly one time before being deleted. It doesn’t matter how big the file is, or how pretty it is. The only thing that matters is that it has to work and it has to be ready by 8am. . There are, of course, the other programs. The ones that people will use for years. In those cases, of course you revisit your code, you clean them up, you document them. . But in a results-oriented and time-critical environment, as I said earlier…. Ugly code that works tomorrow is better than beautiful code that works next week.

If you need to code becaiuse of that, you just plain suck and it's your own damn fault !

2012-03-12 Reply Admin

L.:
Malcolm:
I had a similar experience one time involving surveillance cameras. I was down to the main office for meetings when I heard that they were about to spend $3000 for a video surveillance viewing/recording station. I went out at lunch hour and put one together that cost them a total of $200. . But back to the main point… . Like I said, I’m a big fan of clever coding. I’m in awe of those who can knock out in 5 lines what it takes mere mortals like me 30 lines to do. . But in the painfully real (and fast paced) world I work in (the restaurant industry), there is no next week. I’ll get a call at 8pm telling me something that needs to be deployed in 120 locations by 8AM the following morning. That’s just the way the restaurant business works. And that sort of thing happens all the time. . And the reason for needing the code has nothing to do with problems in prior code. It’s just the nature of that fast-paced beast. For example: You find out at 8pm that your supplier is changing case sizes on a major food item for deliveries that are arriving tonight. Stuff like that. No one is to blame. Nothing could have been done to prevent the problem. It’s just a sh*t sandwich that‘s your job to eat. . And in a case like that, the client will never see the code. It will be run exactly one time before being deleted. It doesn’t matter how big the file is, or how pretty it is. The only thing that matters is that it has to work and it has to be ready by 8am. . There are, of course, the other programs. The ones that people will use for years. In those cases, of course you revisit your code, you clean them up, you document them. . But in a results-oriented and time-critical environment, as I said earlier…. Ugly code that works tomorrow is better than beautiful code that works next week.

If you need to code becaiuse of that, you just plain suck and it's your own damn fault !

Totally agree. If the case size is so important to you and changes so often, you really need to have it stored in a db or something. The real WTF is wokring through the night on something that has to be done by 8am.

2012-03-19 Reply Admin

Are you sure that code is going to compile :? Take a look at line 3 :)

2012-08-24 Reply Admin

His name as a variable is the next generation of A.I.

Dan's Epoch

Leave a comment on “Dan's Epoch”