The Daily WTF: Curious Perversions in Information Technology

da Doctah · 2012-03-05 Reply Admin

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 if that one time zone is Arizona, you don't have to muck about with Daylight Saving Time and have one night a year where there are two 1:34am's.

2012-03-05 Reply Admin

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.

Excuse me? Have you not heard of plate tectonics? Continental drift? Just because they're all in one time zone today doesn't mean you can count on that in the future.

2012-03-05 Reply Admin

C-Octothorpe:
galgorah:
I've found ASP.NET MVC to be a good replacement for classic ASP apps. With ASP.NET MVC you can keep all the old html for a bit and focus on moving code out of the pages. A web designer can then at a later point modernize the presentation without having to weed through code or wrangling with server controls that output their own html. As a result I've found it to be a real time saver over ASP.NET Webforms.
That, and you don't have to fight with the god-awful "page lifecycle", and that each control may or maynot participate in it.

Who actually builds any WebForms projects these days anyway?

2012-03-05 Reply Admin

Jerry:
...plate tectonics...

Fun fact: Southern California is moving north at the rate of a few millimeters per year... about the same speed as your fingernails grow.

-- Useful information for when you want to show off how smart you are. Impresses chicks. (So I've heard.)

2012-03-05 Reply Admin

Jerry:
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.
Excuse me? Have you not heard of plate tectonics? Continental drift? Just because they're all in one time zone today doesn't mean you can count on that in the future.

Amen brother,

Aeons after the earth has decided it's borne the weight of the Himalayas for long enough, long after the insects have won the battle with humans, and long long after ITAPPMONROBOT last searched for the reset button, my code will still be dealing with DateTime objects perfectly.

I like your style.

2012-03-05 Reply Admin

Jay:
geoffrey:
"The over-eager dim a, b, c, d is how Dan began every function. I have found some that declare nearly every letter. But even stranger than that, Option Explicit is never enabled in any of his scripts."
Even if Option Explicit is not turned on, declaring variables early does make a positive difference in performance in ASP code. So it's not really that strange.

The problem with "dim a,b,c,d" is not that it causes a performance problem, but that variables should be given meaningful names an not just sequentially lettered or numbered.

Early binding improves performance, the opposite of what you seem to think.

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.

2012-03-05 Reply Admin

Bruce W:
Anketam:
Schmitter:
PiisAWheeL:
I don't always write code, But when I do, I start with function doseq()
Stay thirsty my friends.
His code carries weight that would break a less WTF man's jaw.
He refactored 10,000 lines of code with a single semicolon.

Chuck Norris broke his leg when he tried to roundhouse kick function doseq().

2012-03-05 Reply Admin

Mine start with

function dofrist()

PiisAWheeL:
I don't always write code, But when I do, I start with function doseq()

PiisAWheeL · 2012-03-05 Reply Admin

Rfoxmich:
Mine start with
function dofrist()

PiisAWheeL:
I don't always write code, But when I do, I start with function doseq()

Sorry dude.. You're on page 2. You fail.

2012-03-05 Reply Admin

Remember, remember the fifth of november!

Yazeran · 2012-03-05 Reply Admin

airdrik:
ClaudeSuck.de:
Philipp:
It seems to me like he had a list of test cases with some dates and their corresponding timestamp values, but it didn't state anywhere that those timestamp values are based on midnight Jan 1st 1970.
So he just took an arbitrary date, compared his results to the desired results, and added the difference.

Why not. The purpose of the code is to create a unique ID. And that is achieved. All right, basically, every second he loses 1 ID but if you only need some thousand IDs it should still be OK.

And no, he won't have year 2038 problem. His will come much later (or earlier, in case he needs 2 IDs in the same second)

CAPTCHA: ingenium, yes this guy was really creative

Now all this guy needs is some mechanism for preventing more than one request for a new unique ID each second.

Oh thats easy, just use a sleep(1) wrapped in a semafore (file lock).... Evil grin

Yours Yazeran

Plan: To go to Mars one day with a hammer

2012-03-05 Reply Admin

It would be interesting to try and tie this WTFs back to forum posts somewhere, to see if this weird ass epoch offset approach was his own idea or something he needed help on and posted to some forum asking "How come it's wrong!?" and the classic "I can't show you my code, obviously, because I don't want you to steal it, just tell me how to fix it."

On a side note, Unix epoch isn't even needed considering the function's purpose. So leaving out the context would have worked just as well...

xtremezone · 2012-03-05 Reply Admin

I feel your pain ...

mihi · 2012-03-05 Reply Admin

geoffrey:
"The over-eager dim a, b, c, d is how Dan began every function. I have found some that declare nearly every letter. But even stranger than that, Option Explicit is never enabled in any of his scripts."
Even if Option Explicit is not turned on, declaring variables early does make a positive difference in performance in ASP code. So it's not really that strange.

It's not only performance. If you happen to use a variable that is defined outside a function, ASP/VBS will reuse the variable (effectively making it global) unless it is declared with dim.


Sub foo()
  dim x
  x = 1
  x = x + 2
  MsgBox x
End Sub

x = 12
MsgBox x
foo()
MsgBox x

This VBS will show 12 3 12, and if you disable the dim it will show 12 3 3. Can be very confusing and also result in endless loops when calling a sub in a for loop and there is another for loop with same iteration variable in the sub without using dim.

2012-03-05 Reply Admin

Sheldon:
Jerry:
...plate tectonics...
Fun fact: Southern California is moving north at the rate of a few millimeters per year... about the same speed as your fingernails grow.

Ah. This explains that recurring item in the Sacramento budget for "research into the development of the world's largest nail clipper."

-Harrow.

2012-03-05 Reply Admin

That is the best comment possible!

QJo · 2012-03-06 Reply Admin

Ralph:
ObiWayneKenobi:
Not surprised. I have yet to see any Classic ASP that was written correctly or anything remotely resembling an attempt to write correctly. Just the equivalent of a monkey typing out code, saving, running in a browser to see if it works, and then typing more code until there are no more errors.
Wow! What planet do you live on? Can I move there? Please???

No no no, don't be silly, he means: "... till the code no longer exits with an error message when presented with the single test case the developer has designed the code to work on."

oheso · 2012-03-06 Reply Admin

ObiWayneKenobi:
Just the equivalent of a monkey typing out code, saving, running in a browser to see if it works, and then typing more code until there are no more errors.

You mean there's another way?

jas88 · 2012-03-06 Reply Admin

Date/time handling can be a whole new WTF. I've been delousing an outsourced app lately which captured daily data. How do you store that? Well, of course, you give each day its own row in the database ... with a "week" column and a "day" column. Data for Thursday would get stored with Monday's date in 'week' and a value of 3 for 'day'. Except for daylight-savings weeks, when it stores Sunday's date in 'week' instead (but still sets day to 3). Oh, and occasionally some get stored with Saturday instead. Maybe from a user accessing it with wrong timezone settings - all the date calculations were done client-side.

What gets stored with 'day' set to either NULL or 7 depending which table you're in? Totals, of course (generated on the Javascript front-end and passed back) - spares the poor database engine the stress of adding up, y'see...

Apart from corrupting the data in fun ways, the front-end goes and creates HTML for every week in the project's timeframe, then hides all but the week being edited. This of course worked in initial testing, then breaks horribly with long or complex projects as IE 6 (yes, have to support that, too) chokes on 100,000+ form fields at once.

2012-03-06 Reply Admin

A Gould:
hobbes:
Nagesh:
Not self-respecting programer is using scripting to try to be doing real work.
Self respecting PROFESSIONALS use whatever tools fix the job. Sometimes that means using a scripted language.
And fun fact: as long as the end user can push a button and The Magic Happens, they could give a flying toss about how it's done. If it works but it's stupid, it still works.

Another fun fact: if it's stupid, and it needs to be touched after it first works, it gets harder and harder to keep it working, and usually gets stupider and stupider in the process too.

Then users start complaining that it works slowly, and corrupts their data.

Then it ends up at here, poorly anonymized.

Of course there's simple solution, just add comments like

// FIXME: ugly and stupid

and my favourite

// TODO: add error handling

2012-03-06 Reply Admin

mott555:
Steve The Cynic:
Annonymous:
Yeah, then he would need a mechanism to ensure that his mechanism to ensure no duplicate IDs doesn't throw exceptions when it is released too often.
Auto-reset Event, *set* once a second by the background thread.

He needs a Java web service with a method that sleeps for a second before returning. Then this method can have the synchronized keyword set. All calls get queued up, get called sequentially, wait a second, and then return. The original project can use this web service as an "enterprise synchronization library."

Much much better . you can use server-side javascript to do the sleep, much better since js's sleep actually makes use of the CPU for the duration ...

2012-03-06 Reply Admin

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.

2012-03-06 Reply Admin

Jay:
geoffrey:
"The over-eager dim a, b, c, d is how Dan began every function. I have found some that declare nearly every letter. But even stranger than that, Option Explicit is never enabled in any of his scripts."
Even if Option Explicit is not turned on, declaring variables early does make a positive difference in performance in ASP code. So it's not really that strange.

The problem with "dim a,b,c,d" is not that it causes a performance problem, but that variables should be given meaningful names an not just sequentially lettered or numbered.

Not really . not when you're doing such overly simplistic stuff. there is NO point in having stupidRetardedLongUglyVariableWeiRDcasEName declared.

2012-03-06 Reply Admin

Mikey:
It would be interesting to try and tie this WTFs back to forum posts somewhere, to see if this weird ass epoch offset approach was his own idea or something he needed help on and posted to some forum asking "How come it's wrong!?" and the classic "I can't show you my code, obviously, because I don't want you to steal it, just tell me how to fix it."
On a side note, Unix epoch isn't even needed considering the function's purpose. So leaving out the context would have worked just as well...

Unix Epoch specifically isn't . but you can't have unique ID's without a time component. the only implementation would be an ever increasing number, transaction safe and that would practically mean a call to the transactional id engine for each id, including disk io. - and that sucks.

2012-03-06 Reply Admin

"But even stranger than that, Option Explicit is never enabled in any of his scripts"

That's not strange at all. This way he can use the variables for whatever data type he wants depending on the function. If that's not a flexible design then I don't know what is. I give it 11 for it's super awesomeness. If you chucked in some XML it might even be enterprise quality code.

2012-03-06 Reply Admin

A Gould:
And fun fact: as long as the end user can push a button and The Magic Happens, they could give a flying toss about how it's done. If it works but it's stupid, it still works.

So you mean they couldn't give a flying toss.

2012-03-06 Reply Admin

Oh come on, thats basic code optimization. Of course it takes longer to calculate the time difference between now and 1970 than between now and 2007. That's over 37 years he does not have to calculate!

PiisAWheeL · 2012-03-06 Reply Admin

Warlaan:
Oh come on, thats basic code optimization. Of course it takes longer to calculate the time difference between now and 1970 than between now and 2007. That's over 37 years he does not have to calculate!

Longer for who? The programmer or the computer? If that's the case, someone should optimize a foot up dan's ass.

callcopse · 2012-03-06 Reply Admin

geoffrey:
Jay:
geoffrey:
"The over-eager dim a, b, c, d is how Dan began every function. I have found some that declare nearly every letter. But even stranger than that, Option Explicit is never enabled in any of his scripts."
Even if Option Explicit is not turned on, declaring variables early does make a positive difference in performance in ASP code. So it's not really that strange.

The problem with "dim a,b,c,d" is not that it causes a performance problem, but that variables should be given meaningful names an not just sequentially lettered or numbered.

Early binding improves performance, the opposite of what you seem to think.

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.

It's not that it is hard to get the meaning by mentally parsing the code, but why on earth should you? Essentially coders who relax naming standards 'because the function is simple' are the same numpties that would use any old excuse to churn out shite (sore point at the mo, sorry, wrestling with some funky technical debt here). All methods should be short anyhow, doesn't reduce the need to document what is going on.

2012-03-06 Reply Admin

callcopse:
geoffrey:
Jay:
geoffrey:
"The over-eager dim a, b, c, d is how Dan began every function. I have found some that declare nearly every letter. But even stranger than that, Option Explicit is never enabled in any of his scripts."
Even if Option Explicit is not turned on, declaring variables early does make a positive difference in performance in ASP code. So it's not really that strange.

The problem with "dim a,b,c,d" is not that it causes a performance problem, but that variables should be given meaningful names an not just sequentially lettered or numbered.

Early binding improves performance, the opposite of what you seem to think.

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.

It's not that it is hard to get the meaning by mentally parsing the code, but why on earth should you? Essentially coders who relax naming standards 'because the function is simple' are the same numpties that would use any old excuse to churn out shite (sore point at the mo, sorry, wrestling with some funky technical debt here). All methods should be short anyhow, doesn't reduce the need to document what is going on.

No just no . short var names are cool. I like em.

2012-03-06 Reply Admin

Joey:
Minos:
Look at it the other way: select dateadd(s, 1194231874, '1970-01-01') 2007-11-05 03:04:34.000
The reference date for Dan's Epoch appears to be UTC -8 and the conversion is off by 11 seconds.

That '1970-01-01' literal is subject to locale-specific mangling. Here's what PostgreSQL gives me:
> select timestamptz 'epoch';
      timestamptz       
------------------------
 1969-12-31 19:00:00-05
(1 row)

> SELECT timestamptz 'epoch' + '1194231874 seconds';
        ?column?        
------------------------
 2007-11-04 22:04:34-05
(1 row)
It appears Dan's Epoch is based on central time (UTC-6), and the conversion is off by 13 seconds.

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.

2012-03-06 Reply Admin

jas88:
Date/time handling can be a whole new WTF. I've been delousing an outsourced app lately which captured daily data. How do you store that? Well, of course, you give each day its own row in the database ... with a "week" column and a "day" column. Data for Thursday would get stored with Monday's date in 'week' and a value of 3 for 'day'. Except for daylight-savings weeks, when it stores Sunday's date in 'week' instead (but still sets day to 3). Oh, and occasionally some get stored with Saturday instead. Maybe from a user accessing it with wrong timezone settings - all the date calculations were done client-side.
What gets stored with 'day' set to either NULL or 7 depending which table you're in? Totals, of course (generated on the Javascript front-end and passed back) - spares the poor database engine the stress of adding up, y'see...

Apart from corrupting the data in fun ways, the front-end goes and creates HTML for every week in the project's timeframe, then hides all but the week being edited. This of course worked in initial testing, then breaks horribly with long or complex projects as IE 6 (yes, have to support that, too) chokes on 100,000+ form fields at once.

Never mind the (likely) SQL Injection opportunities... this crapp lets the browser choose the value of the ID that will be used to store stuff in the database??? {huge}WTF????!!!!!{/huge} Should be opportunities for enormous fun there!

Coyne · 2012-03-06 Reply Admin

Of course he uses a, b, c, d, and etc. You have to be careful with that new-fangled stuff like a1, a2, a3, b1, b2, b3, and etc.

After all, razor-edge = bleeding-edge.

PiisAWheeL · 2012-03-06 Reply Admin

Coyne:
Of course he uses a, b, c, d, and etc. You have to be careful with that new-fangled stuff like a1, a2, a3, b1, b2, b3, and etc.
After all, razor-edge = bleeding-edge.

You ever seen anybody go aa, ab, ac, ad... like how ms excel does when you scroll past 26 columns to the right... I don't remember where I saw it, but I hope to never see it again.

Matt Westwood · 2012-03-06 Reply Admin

L.:
callcopse:
geoffrey:
Jay:
geoffrey:
"The over-eager dim a, b, c, d is how Dan began every function. I have found some that declare nearly every letter. But even stranger than that, Option Explicit is never enabled in any of his scripts."
Even if Option Explicit is not turned on, declaring variables early does make a positive difference in performance in ASP code. So it's not really that strange.

The problem with "dim a,b,c,d" is not that it causes a performance problem, but that variables should be given meaningful names an not just sequentially lettered or numbered.

Early binding improves performance, the opposite of what you seem to think.

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.

It's not that it is hard to get the meaning by mentally parsing the code, but why on earth should you? Essentially coders who relax naming standards 'because the function is simple' are the same numpties that would use any old excuse to churn out shite (sore point at the mo, sorry, wrestling with some funky technical debt here). All methods should be short anyhow, doesn't reduce the need to document what is going on.
No just no . short var names are cool. I like em.

No they're not. They're shit like you.

2012-03-06 Reply Admin

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.

PiisAWheeL · 2012-03-06 Reply Admin

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.

Nice Master Thesis :p I like to declare variables right before I use them (or before the loop), name them appropriately (small but descriptive) and then when I finish the function I move them all up to the top of the function.

Then again a lot of my code probably belongs on this sight and would give "good coding standards" people a stroke.

jas88 · 2012-03-06 Reply Admin

Bobby:
Never mind the (likely) SQL Injection opportunities... this crapp lets the browser choose the value of the ID that will be used to store stuff in the database??? {huge}WTF????!!!!!{/huge} Should be opportunities for enormous fun there!

Ohh yes. Security is still on the 'TODO' list. The outsourced server-side code had a huge security library bolted on which checked very carefully that the user was indeed a valid one before letting them read or write user data. It did forget to check that it was your data you were accessing though ...

It had 3 layers of access: user, company admin, system admin. Company admins could reset users' passwords. ALL user passwords, whichever company they were associated with.

(Inputs are pretty solidly checked now, at least, but after the last round of layoffs time to fix bugs is in short supply.)

2012-03-06 Reply Admin

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

2012-03-06 Reply Admin

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.

Matt Westwood · 2012-03-06 Reply Admin

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.

2012-03-06 Reply Admin

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.

2012-03-06 Reply Admin

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.

2012-03-06 Reply Admin

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.

The Bytemaster · 2012-03-06 Reply Admin

Jerry:
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.
Excuse me? Have you not heard of plate tectonics? Continental drift? Just because they're all in one time zone today doesn't mean you can count on that in the future.

You forgot the biggest force in the universe: Politicians! Maybe they decide to redraw the lines at any given moment...

2012-03-06 Reply Admin

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 there is the problem-- that and the other developer who asserted that because he didn't know what he was going to do in the code, he'd just declare some variables and get started typing, as if that was just fine. If you don't know what you're going to do and have no standards for how you do it, your code will inevitably be shite and you won't even know why anyone else would think so.

As for writing one-off scripts (or tools or whatever)-- if you write crap code each time, I can understand not reusing it. However, I have a library of quick-response code I've written for systems I've supported over the years, and I can respond much faster because I still put the time into making them reasonably well structured; I can call up and reuse decent code because it works well and I can see clearly what it's doing, so if I have a different need, the basics are there and tested, and it's easy to see what to do for the new need.

Imagine:

float fnGH(float a, float b) { float z = 3.1416;

return f(b*k,2)*a; }

or

float CircleArea(float radius) { float pi = 3.1416;

return power(radius, 2) * pi;

}

Now-- how much longer did one take to type? I suggest, if you are a professional programmer, the second didn't take any longer than the first. I also suggest that if you are a professional programmer, the first would take more from your self esteem than the typing the second took from your time.

Matt Westwood · 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.

Who said he was "wise"? Quite frankly I think he was an overpaid shithead. Any cunt coming out with fucking crap like that on my watch would be out of the door so fast he'd break the light barrier.

Matt Westwood · 2012-03-07 Reply Admin

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.

2012-03-07 Reply Admin

PiisAWheeL:
Coyne:
Of course he uses a, b, c, d, and etc. You have to be careful with that new-fangled stuff like a1, a2, a3, b1, b2, b3, and etc.
After all, razor-edge = bleeding-edge.
You ever seen anybody go aa, ab, ac, ad... like how ms excel does when you scroll past 26 columns to the right... I don't remember where I saw it, but I hope to never see it again.

Have you ever seen SpectateSwamp's code?

2012-03-07 Reply Admin

Matt Westwood:
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.

Who said he was "wise"? Quite frankly I think he was an overpaid shithead. Any cunt coming out with fucking crap like that on my watch would be out of the door so fast he'd break the light barrier.

Maybe it should be: "Solve tomorrow's problems today, as today's problems were already solved yesterday."

Dan's Epoch

Leave a comment on “Dan's Epoch”