• Quite (unregistered)

    Yeah, BTDTBTT.

    Currently putting in an emergency last-minute workround to a bug that the back-end team have known about for the last 2 years (if you update a record to make it have fewer entities than it did, it fails to reset the high-index fields to blank, so the damn thing contains spurious data -- best case scenario is that it looks as though the update was never made, and worst case the update fails because the data is internally inconsistent).

    So I've been bodging it to explicitly set the high-end records to blank from the front end (I know, I know, I hate myself) and lordy gordy blordy, what happens? You can't set this field to blank because it's got to be one of a set of allowed values.


  • (nodebb)

    Y2K first started to bite (at least a bit) in 1970 when the last-payment dates of new 30-year mortgages started to be in 2000, or, perhaps more to the point, in 1900.

    And of course when I was doing some research about something that happened in the 19th century, I found a pre-printed form, completed by hand in 1859, with the "year" spot pre-printed as 185__...

  • Pjrz (unregistered)

    All goes to prove that nobody really looks at all those thousands of reports that company directors insist get generated every day.

  • TVJohn (unregistered) in reply to Pjrz

    How very true. One place I worked at the management wanted a new report designed almost every month. The old one was clearly only used the once and then discarded.

  • DQ (unregistered)

    I used to do the reporting for our company. One day our sales manager asked me to create a new report and I had to answer 'I already make this every month' :( Shortly after that I stopped making all these monthly reports except for a few I knew that were really used. Never got any questions about the others. It saved me hours every month :)

  • Sole Purpose of Visit (unregistered)

    Not much to like about that function at all, is there? Stupid name, effectively no error handling, trashes the entire database (or at least that part to do with widgetsinc, doesn't do the job, failure to write the ten-line-long test that would validate correct behavior ...

    Interestingly (and purely by coincidence), an error on the first insert would set the return value to precisely the same value returned by a wraparound. Which has a certain piquancy to it. And conversely if the same "did the insert work?" test was performed on the wraparound insertion, the functional flaw would be immediately obvious ...

    It's too polite to call this "technical debt." There's nothing noticeably technical about it at all.

  • isthisunique (unregistered)

    I've made something like this before. The original implementation I inherited was someone putting in rand and selecting until it returned null. I replaced it with something in the background that pre-generates IDs and puts the uncertainty on a background task instead. I never liked it though and always just wanted to use auto-increment. One of the reasons something like that is a mess is not only because it needs to keep ahead but getting transactional things like that right in certain DBs is really awkward and often requires strange things if you want to pessimistic locking to work properly for example.

    I eventually had time to look at the problem properly and replaced it with hand implemented FPE. This makes like infinitely easier, despite FPE being tricky to implement and then to confirm within reason that it's actually correct and secure. It's annoying that not more database systems ship with FPE built in.

  • isthisunique (unregistered)

    No wait worry I haven't implemented something like this before. Isn't this just auto-increment done FUBAR?

  • Altaree (unregistered)

    Sounds like someone is used to working with an old version or Oracle with its sequences table. I would love to see what happens when two rows have the same id...

  • RichP (unregistered)

    I got 999,999 problems but a code review just aint one!

  • masonwheeler (github)

    This is why the death penalty doesn’t deter crime,

    Says who? Certain people like to say that, that all the murderers out there on Death Row prove this, but it's important to keep survivorship bias in mind. (https://xkcd.com/1827/) When all we see is the ones it didn't deter; we have no good way of measuring how many it did.

  • 🤷 (unregistered) in reply to masonwheeler

    Well, the murder rate isn't really lower in states with death penalty than in those states without death penalty, right? Or at least, that's what I read. I don't have any numbers at hand to back up my statement.

  • Sole Purpose of Visit (unregistered) in reply to masonwheeler

    I think the normal scientific method of selecting two sizeable populations of roughly similar characteristics (thus controlling for all other variables) and then measuring the rate of murder with/without would do.

    You're the one making the assertion that there's no proof that this specific deterrent doesn't work. I suggest that you try to prove the positive. You can even use historical evidence for any two States before and after Gary Gilmour, which is handy for statistical purposes.

  • 🤷 (unregistered) in reply to Pjrz

    "All goes to prove that nobody really looks at all those thousands of reports that company directors insist get generated every day."

    Yeah. I once was tasked to write up a new report, which took about a week to implement, test, etc. pp. I then asked at which days the report should run and I never got an answer to that. So, the report was ready to be used, but it never went live.

  • Jon (unregistered)


  • Sole Purpose of Visit (unregistered)

    On a more general note, this is a salutary example of how semi-educated CS bods don't really understand the concept of "types." Parenthetically, I will point out that Python 3 has finally disabused itself of the notion that a "string" is just a sequence of "bytes." (I haven't yet had to figure out how this plays out over the wire with things like ntohs and vice-versa, but I devoutly hope that this stuff is handled at a lower level, transparently, in the libraries.)

    Similarly, a database auto-increment sequence may look like it's an integer ... but it really isn't. It's a whole different type, as this abomination demonstrates all too clearly. I worry about "professionals" who don't recognise this obvious fact, because built-in types (for a typed language) are about as simple as it gets. Heaven forbid these people have to deal with polymorphism, or type inference, or covariancy/contravariancy. Well, I say that. They'll probably just use a C-style cast on an object and have done with it.

    None of that really excuses the gratuitous trashing of the database, though. At some level of accountability, Messrs Sarbanes and Oxley will surely need to have a word.

  • Eric Gregory (github)

    I don't understand how a business requirement would involve limiting the range on a database ID. Is this just one of those situations where the company is too cheap to pay for the amount of storage they need?

  • Zenith (unregistered) in reply to 🤷

    Same here. I was drafted to do a new reporting system after being drafted to replicate a VB5 program in SSRS. I was given a list of tickets with vague info and occasionally a half-baked query. So I did a random 10 and stopped because I had other stuff to do and submitted what I had for review. Never hear any responses from anybody but occasionally I get a request for a status report that I basically blow off with "waiting for feedback on X Y Z." I haven't decided whether they think IT is sorcery or thoughtlessly easy yet.

  • Brian (unregistered) in reply to Pjrz
    All goes to prove that nobody really looks at all those thousands of reports that company directors insist get generated every day.

    Reminds me of my former employer. Every Friday, every team member had to write up a status report for the week and send it to the team lead. Each team lead would then compile these reports into a team status report and send that to the project manager. The project managers would compile these reports into a project status report and send it to the division head. And so on, presumably up the chain to the president. So you can imagine how much information was lost in each step, plus all the man-days that were spent every week writing these reports. And of course, I would frequently get asked questions to which my response would be "See my status report from last week. And the week before that, and the week before that..."

    It was especially bad when I was a dev lead and basically spent the majority of every Monday writing the dev team report, complete with burndown graphs and such (because all the managers really cared about were pretty pictures and not the actual problems the team was having). And of course I was also the primary developer on the team, so my #1 complaint on every report was that the project was behind schedule because the team was understaffed and I was spending 20% of my time writing these stupid reports that no one really reads. But I'm sure no one actually read that.

  • Tim! (unregistered) in reply to masonwheeler

    The murder rate in states without the death penalty is lower than in states with the death penalty. https://www.amnestyusa.org/issues/death-penalty/death-penalty-facts/the-death-penalty-and-deterrence/

    Crimes for which the death penalty can apply are most often crimes of passion. Zero consideration for any consequence enters into the decision to commit a crime of passion.

    The punishment side of our justice system is billed as both deterrent and rehabilitation but routinely fails at both. The only end to which prison or the death penalty succeed is putting undesirables out of sight so the rest of us don't have to think about the real problems and circumstances they emerged from.

  • Bob (unregistered) in reply to Eric Gregory

    The "business requirement" is probably that the ID number is used in lots of other legacy systems and reports. most of which predate SQL as a data storage paradigm. And those systems all expect the ID number to be 6 characters in length and be numeric.

  • Loren Pechtel (google) in reply to Bob

    Yup, it's pretty obvious this is the problem.

  • DrPepper (unregistered) in reply to masonwheeler

    True enough that penalties don't deter crime. I know someone who stabbed his brother and killed him; over a rent money argument. He certainly has seen his share of TV dramas; and knew what would happen to him. Did it anyway. Stupidity, drugs, and alcohol will overwhelm you in the heat of the moment; and it's only later that you think of the consequences.

    Same with writing code, by the way -- Stupidity will overwhelm you; and it's only later, when you go back and read your code again, do you realize the crime you committed by writing it.

  • Scott Christian Simmons (google)

    I fixed a Y2K bug in 1999, in a javascript module that was originally written in 1998.

    The original dev had left the company, so I never got the chance to ask him WHAT IN THE SAM HILL WERE YOU THINKING, YOU DROOLING NOBWIT?!

  • Dan (unregistered)

    The death penalty is invoked so rarely these days and carried out so far into the future from conviction that it's pretty much invisible as a potential penalty. As Remy said, "One of the more interesting things about human psychology is how bad we are at thinking about the negative consequences of our actions if those consequences are in the future."

    If you REALLY want to know whether the death penalty works, ask how many people are willing to steal from organized crime.

  • Derp (unregistered)

    I don't know why this is so complicated.

    function getstan() { return stan; }

  • RLB (unregistered) in reply to Scott Christian Simmons

    I fixed a Y2K bug in 1999 (or maybe 1998) in code that was written in 1995. By me. Against my better judgement but at the insistence of mgmt. (1995: "What do you mean, enter four whole digits? We can't be doing that! Fix it!" 1998: "You will fix this horrible bug you programmers have introduced and fix it now!" Well, ok, not quite that rudely, but quite that stupidly.)

    Of course, I'd made sure in 1995 that the fix I knew would be demanded a few years later would be very easy to implement indeed...

  • LzzrdBorth (unregistered) in reply to TVJohn

    My favorite was developing reconciliation reports. It became much easier when I realize nobody actually double-checked them, so just make the "total" of a column the same as the number it's supposed to match, and you never get into trouble.

  • markm (unregistered) in reply to Eric Gregory

    Perhaps the "business requirement" is that the ID fit in a 5-digit decimal field - and management thought that duplicate ID's and discarding old data would be preferable to re-printing a form. If the records age consistently and are not being generated too quickly, duplicate ID's may be no problem, because the old record with the same ID is no longer relevant. That's assuming that the company doesn't grow too much - but it's likely that such an increase in scale would soon involve a revamp of all the business processes and forms, whether such changes are required or just a new CEO's brainstorm...

    But this is still a terrible way to handle it. If $sequence has a special meaning to the database, generate the ID separately from it. In some cases, you could even use ($sequence modulo 99999)+1 for the ID. Either use a search method that will present the duplicates with dates, "Do you want record #00001 from 2018 or from 2005?", or set up a process that moves the outdated records to an archive so duplicates only exist if you have to search the archives. Better yet, have inactive records marked and moved to archives, and check whether there's a record that is still active before assigning a re-used ID. E.g., a manufacturing plant I once worked at ran out of internal part numbers. Rather than changing the # of digits (which would require simultaneous updates everywhere), they went back to the beginning - but if the next part number was still in use, they'd skip it and go to the next one. It eventually got to where numbers that I could easily remember from two or three years earlier were being re-used, but a decade of stupid management drove them bankrupt before it really became a problem.

  • markm (unregistered) in reply to Dan

    My understanding is that mob hitmen keep in practice with mob members stupid enough, or so lacking in impulse control, as to steal from the mob, sleep with the boss's girlfriend, etc. When you hire crooks, often you get people who are incapable of honesty no matter how great the consequences...

    No doubt the death penalty would deter you or me, but we're not likely to murder anyone anyhow. When someone has the cluster of character defects that make him likely to murder, it will often come with other defects, such as an inability to look to the future and guide his actions accordingly, and/or extreme recklessness. And frankly, if I was driven to murder, Michigan's life-without-parole sentence would bother me quite as much as the possibility that if I did it in another state, I might be caged for 20 or 30 years until all the lawyers ran out of delaying tactics and forlorn hopes, and then finally executed.

  • Peter Bouillon (unregistered) in reply to Sole Purpose of Visit

    There's an interesting chapter in Freakonomics about this. The gist is that living the daily life of a drug peddler has a much higher death threat – higher by orders of magnitude – than the actual death threat of the justice: Death sentences are carried out in such a low frequency in America that the day-to-day risk of dying actually drops very steeply when you are caught and actually put_into_death_row.

    So there's no economic reason whatsoever why the death penalty could deter anyone from doing anything bad whatsoever.

  • Erik Gern (unregistered)

    stopped reading at "greenhouse gases". go peddle your politics somewhere else.

  • David (unregistered) in reply to Erik Gern

    So why exactly is Y2038 not politics and "greenhouse gases" is? Declaring an issue to be politics doesn't change anything.

Leave a comment on “Waiting for the Future”

Log In or post as a guest

Replying to comment #:

« Return to Article