• daniel (unregistered)

    For crying out loud; RDN is still not free, and has never been. That is, my dear watson32.exe, the true wtf in this story.

  • (cs)

    Is there any reason at all to use Random in business software?

  • Nutmeg Programmer (unregistered)

    This is a Bohr bug, the most dependable kind.

    heisenbug: /hi:'zen-buhg/ n. [from Heisenberg's Uncertainty Principle in quantum physics] A bug that disappears or alters its behavior when one attempts to probe or isolate it. (This usage is not even particularly fanciful; the use of a debugger sometimes alters a program's operating environment significantly enough that buggy code, such as that which relies on the values of uninitialized memory, behaves quite differently.)

    Bohr bug: /bohr buhg/ n. [from quantum physics] A repeatable bug; one that manifests reliably under a possibly unknown but well-defined set of conditions.

    mandelbug: /man'del-buhg/ n. [from the Mandelbrot set] A bug whose underlying causes are so complex and obscure as to make its behavior appear chaotic or even non-deterministic. This term implies that the speaker thinks it is a Bohr bug, rather than a heisenbug.

    schroedinbug: /shroh'din-buhg/ n. [MIT: from the Schroedinger's Cat thought-experiment in quantum physics] A design or implementation bug in a program that doesn't manifest until someone reading source or using the program in an unusual way notices that it never should have worked, at which point the program promptly stops working for everybody until fixed. Though (like bit rot) this sounds impossible, it happens; some programs have harbored latent schroedinbugs for years.

  • rqm (unregistered) in reply to SpComb

    Sorry, couldn't resist.

    from random import random L = [int(random() * 100) for _ in range(int(random() * 100))] print L

  • kgj (unregistered)

    Calling it a "fluke" should tell management that the developer has ... a whale of a problem.

  • Dev Mgr (unregistered)

    Not true. Bizarre data flukes happen all the time.

    If you really believe that, do not bother to seek employment in my department. there is always a reason for 'data flukes'.

    A coder turned dev manager

  • Franz Kafka (unregistered) in reply to Salami
    Salami:
    Is there any reason at all to use Random in business software?

    yeah. It's handy for spreading load over time. Use it for some scheduled processes and during startup in high throughput environments.

  • (cs) in reply to Dev Mgr
    Dev Mgr:
    > Not true. Bizarre data flukes happen all the time.

    If you really believe that, do not bother to seek employment in my department. there is always a reason for 'data flukes'.

    A coder turned dev manager

    Your irony detector needs to be adjusted. Or turned on. Or you need to get one.

  • jwatzman (unregistered) in reply to Anon Fred
    Anon Fred:
    But a lot of real-world applications rely upon the incredible rarity of collisions of random numbers. Such as the Andrews File System.

    Care to elaborate, or give a reference? I'm at CMU and of course AFS is still very common around here. People are always saying how horrible and buggy AFS is, so anything I can read about it I'm interested in.

    (It's not that I don't believe you, I'm just curious. A quick google didn't turn up anything.)

  • gbartram1 (unregistered)

    OMG! I haven't programmed in 10 years, and yet even I recognized the flaw due to the "psuedo-random" numbers. How clueless can these developers be?

    And I have to agree with operagost. If anyone pulled that "fluke" explanation working under me, they'd be working late developing a thorough understanding of the term "fluke".

  • blindman (unregistered) in reply to Anon
    Anon:
    In any case, you're limited in the number of GUIDs per unit time you can generate so they make a really lousy ID number.
    Flat out wrong. And GUIDs have many functional coding advantages over identities. In most applications they end up being more efficient because the prevent the need to make additional database calls to get SCOPEIDENTITY, and they invariably make data merging and migration a breeze. I always use GUIDs, except in cases where my clients have been misled by the misinformed into thinking that they are bad.
  • James (unregistered)

    Another WTF here is that anyone is arguing that using PRDs is somehow acceptable.

  • Retardicon (unregistered) in reply to blindman
    blindman:
    Anon:
    In any case, you're limited in the number of GUIDs per unit time you can generate so they make a really lousy ID number.
    Flat out wrong. And GUIDs have many functional coding advantages over identities. In most applications they end up being more efficient because the prevent the need to make additional database calls to get SCOPEIDENTITY, and they invariably make data merging and migration a breeze. I always use GUIDs, except in cases where my clients have been misled by the misinformed into thinking that they are bad.
    I'd imagine that depends on the generation algorithm. If Mr. Anon really wants to waste 6 bytes (that's a MAC address, right?) when generating his GUIDs, that's his problem. But anyone using Microsoft's GUIDgen can easily prove that real GUID generators don't do that, and that they're not time based either.

    In any case, GUIDs are still generally a bad idea for primary keys. Not always, of course, but most databases have data added a row at a time. In that case, a simple sequence makes much more sense than GUIDs.

  • Scottford (unregistered) in reply to Dev Mgr
    Dev Mgr:
    > Not true. Bizarre data flukes happen all the time.

    If you really believe that, do not bother to seek employment in my department. there is always a reason for 'data flukes'.

    A coder turned dev manager

    But the "reason" could be something completely unpredictable and unreproducible, like an alpha particle ("cosmic rays") switching a bit in memory from 0 to 1.

    It happens, more and more as transistors get smaller. That's why they have ECC memory.

  • (cs)

    The REAL WTF is that Dan did NOTHING after the first bug was closed.

    It is one thing if Dan is busy and trusted his developer. BUT Dan claimed he had his suspisions what the problem was... AND yet still trusted the dev, when the dev said there wasn't a problem.

  • (cs) in reply to KattMan
    KattMan:
    gabba:
    Not true. Bizarre data flukes happen all the time. I think that explains this hard to find bug I'm supposed to be working on right now.

    Not true, there are no bizzare data flukes. There are extremely hard to find bugs. A computer will NOT simply decide to do something different in rare cases. There is always a reason, the problem is trying to find that reason. This is more of a fringe case rather than a fluke, but it is repeatable given the same circumstances. Finding what those circumstances are is the difficult part. No one said this job was supposed to be easy.

    Actually there ARE bizzare data flukes. A computer CAN decided to simply do something different in rare cases. Faulty memory, bad voltage, faulty disk drives.

  • (cs) in reply to Flash
    Flash:
    brazzy:
    operagost:
    A good manager simply would have informed the bug owner that "must be a fluke" is not a valid conclusion after the first bug report was closed.
    What do you do when you get assigned a bug that you cannot reproduce?

    You request permission to put more tracing code in the Production system. (But that's only if you really can't reproduce it.)

    If you want to try to reproduce every bug yorself, you'll never get any work done (given a sufficiently large application). Rather, have the reporter provide you with a reproducible example. That way, you can be sure that it is a bug and not a user being too stupid and not admitting it.

  • Tries harder (unregistered) in reply to brazzy
    brazzy:
    operagost:
    A good manager simply would have informed the bug owner that "must be a fluke" is not a valid conclusion after the first bug report was closed.
    What do you do when you get assigned a bug that you cannot reproduce?
    Try harder.
  • (cs) in reply to gomer
    gomer:
    guids are your friends.
    What's guid for the goose is guid for the gander.
  • BS (unregistered) in reply to Vlad Patryshev
    Vlad Patryshev:
    While fixing this is a good thing, wasting meeting time explaining to the incompetent subordinates how RNG works is an abuse of authority. See why. If you are in the coder's hat, act like a coder. Fix it, talk to the guy who was responsible for the bug, and keep it quiet. Or write a short unassuming memo. But please don't patronize. You may be a manager, but this does not mean you thusly become a super-coder, omniscient and omnipotent.
    Bullsh*t. Tear the dev a new one...
  • DLikhten (unregistered)

    I find it funny that he actually said "OK" to the resolutions...

    I have NEVER had a manager who assigned me a bug and would accept anything other than: "The issue is caused by xyz" and MAYBE we may decide that we can fix it later or its not something major and we don't have time to fix it...

  • civil servant (unregistered) in reply to Salami
    Salami:
    Is there any reason at all to use Random in business software?
    I used to work on the jury selection application for county government. We'd have been breaking the law if we **didn't** use RANDOM. In fact, we were subpoenaed more than once by defense attorneys trying to prove our system, was biased.
  • DLikhten (unregistered) in reply to chrismcb
    chrismcb:
    KattMan:
    gabba:
    Not true. Bizarre data flukes happen all the time. I think that explains this hard to find bug I'm supposed to be working on right now.

    Not true, there are no bizzare data flukes. There are extremely hard to find bugs. A computer will NOT simply decide to do something different in rare cases. There is always a reason, the problem is trying to find that reason. This is more of a fringe case rather than a fluke, but it is repeatable given the same circumstances. Finding what those circumstances are is the difficult part. No one said this job was supposed to be easy.

    Actually there ARE bizzare data flukes. A computer CAN decided to simply do something different in rare cases. Faulty memory, bad voltage, faulty disk drives.

    Dude...

    Blame the computer as a LAST result. Run Prime95 for 10 min once on each of the 3 stress test settings to check the memory processor. If any errors come up THEN you can CONSIDER that being the cause.

    Randomly switching registers or memory is all BS... But I would love to see someone accept that explanation.

  • RTFC (unregistered)

    "the importance of reading the documentation"

    Now there's the real WTF. The documentation has nothing to do with the code. If you want to know what the code is doing, you read the code. If you read the documentation, you add code that depends on the documentation, you add bugs. RTFD? FOAD.

  • lorcan (unregistered) in reply to Vlad Patryshev
    Vlad Patryshev:
    While fixing this is a good thing, wasting meeting time explaining to the incompetent subordinates how RNG works is an abuse of authority. See why. If you are in the coder's hat, act like a coder. Fix it, talk to the guy who was responsible for the bug, and keep it quiet. Or write a short unassuming memo. But please don't patronize. You may be a manager, but this does not mean you thusly become a super-coder, omniscient and omnipotent.

    Bullshit - You may be a coder, but this does not mean you thusly become a super-coder, omniscient and omnipotent, and know everything - if you did, you would be called an "owner" - you know, the guy (or gal) you work for.

  • Kaon (unregistered) in reply to Vlad Patryshev
    Vlad Patryshev:
    While fixing this is a good thing, wasting meeting time explaining to the incompetent subordinates how RNG works is an abuse of authority. See why. If you are in the coder's hat, act like a coder. Fix it, talk to the guy who was responsible for the bug, and keep it quiet. Or write a short unassuming memo. But please don't patronize. You may be a manager, but this does not mean you thusly become a super-coder, omniscient and omnipotent.

    I find it amusing that people actually refuse to learn, and refuse to be taught. If the dipwad developers had no clue, they deserved a lecture. It's not patronizing, it's pragmatics. That, or essentially "WTF did you during your CS education (whether formal or self-taught)"?!

    I wish I had a "boss" who would be better than I am at things that I do and could teach me new tricks. He's a great mech. engineer, and I've learned most what I know from him in that area, but software and electronics isn't his background, and that's what I always need to learn more of.+

  • Kuba (unregistered) in reply to Al H
    Al H:
    I had a similar problem with SQL numbers awhile back, and since it was written by a SQL "guru" (or so he said) I never thought it could possibly be his code. Especially since he said it couldn't. So after years of patching other code to avoid it (and after he took his guruness to another company) I discovered his "unique number" logic was even less unique than a random.

    Basically, he took today's julian as the "base" and added a sequence number to each row of data. Which worked fine the first time it ran each day. The 2nd time would cause an error.

    The "newid()" function in SQL is there for a reason...

    Nah, that's not enterprisey enough. You ought to deploy an application server, which serves an increment-per-request counter value. Then your DB application issues a SOAP call to the server to get the updated counter value.

    Cheers!

  • Kuba (unregistered) in reply to DLikhten
    DLikhten:
    chrismcb:
    KattMan:
    gabba:
    Not true. Bizarre data flukes happen all the time. I think that explains this hard to find bug I'm supposed to be working on right now.

    Not true, there are no bizzare data flukes. There are extremely hard to find bugs. A computer will NOT simply decide to do something different in rare cases. There is always a reason, the problem is trying to find that reason. This is more of a fringe case rather than a fluke, but it is repeatable given the same circumstances. Finding what those circumstances are is the difficult part. No one said this job was supposed to be easy.

    Actually there ARE bizzare data flukes. A computer CAN decided to simply do something different in rare cases. Faulty memory, bad voltage, faulty disk drives.

    Blame the computer as a LAST result. Run Prime95 for 10 min once on each of the 3 stress test settings to check the memory processor. If any errors come up THEN you can CONSIDER that being the cause.

    I second that. memtest86 and prime95 are my tools of choice when someone complains of flaky hardware.

  • RandomJoe (unregistered) in reply to blindman

    GUIDs are useful too if you're returning the ID number back to the customer.

    It adds one more layer of difficulty for a malicious user to look at someone else's order/reservation/whatever.

    Say the customer's status page is http://foo.com/status.php?id=4392.

    If they can just increment the id and see someone else's data, that's bad.

    If it's http://foo.com/status.php?id=439fa2e8c8d8e, they're going to have a harder time finding the next URL to try (obviously this can't be the only layer, but it can be a layer.

  • rawr (unregistered) in reply to KattMan
    KattMan:
    gabba:
    Not true. Bizarre data flukes happen all the time. I think that explains this hard to find bug I'm supposed to be working on right now.

    Not true, there are no bizzare data flukes. There are extremely hard to find bugs. A computer will NOT simply decide to do something different in rare cases. There is always a reason, the problem is trying to find that reason. This is more of a fringe case rather than a fluke, but it is repeatable given the same circumstances. Finding what those circumstances are is the difficult part. No one said this job was supposed to be easy.

    Actually, a computer may be coerced to miss a calculation here and there from cosmic radiation and all kinds of interesting stuff. That is what I'd refer to as bizarre fluke. ;)

  • EPE (unregistered) in reply to brazzy
    brazzy:
    operagost:
    A good manager simply would have informed the bug owner that "must be a fluke" is not a valid conclusion after the first bug report was closed.
    What do you do when you get assigned a bug that you cannot reproduce?
    Brave men just need to look at the code.
  • EPE (unregistered) in reply to Flash
    Flash:
    brazzy:
    operagost:
    A good manager simply would have informed the bug owner that "must be a fluke" is not a valid conclusion after the first bug report was closed.
    What do you do when you get assigned a bug that you cannot reproduce?

    You request permission to put more tracing code in the Production system. (But that's only if you really can't reproduce it.)

    I would never alloy such thing to happen in my production systems, nor anybody I know.

  • CynicalTyler (unregistered) in reply to blindman
    blindman:
    the chance of two machines generating the same GUID really IS infinitesimally small
    Infinitesimally small is infinitely larger than exactly zero, which is what you get if you use a sequence where you can guarantee wrapping is not a problem.
    RandomJoe:
    GUIDs are useful too if you're returning the ID number back to the customer.
    Ibuprofen is useful too if you're going to shoot yourself in the foot. I would much rather encode such values, or better yet, avoid returning them at all.

    Oh and don't feed me the line about using GUIDs for spanning databases across machines. Saying "there's a really small chance of GUIDs colliding, so let's just use it" is logically the same as saying "we did not bother to eliminate the possibility of failure".

  • (cs)

    The generation of random numbers are to important to be left to chance:

    #define actual_random 7

    int random_int(int seed){ return actual_random; }

  • Curtis (unregistered) in reply to proko

    Actually, I believe RFC 1149.5 specifies 4 as the standard IEEE-vetted random number.

    int getRandomNumber() { return 4; // chosen by fair dice roll. // guaranteed to be random. }

  • Figs (unregistered) in reply to ParkinT

    I guess it's gone down in recent years. Used to be higher. ;)

  • tacticus (unregistered) in reply to Martin Dreier
    Martin Dreier:
    If you want to try to reproduce every bug yorself, you'll never get any work done (given a sufficiently large application). Rather, have the reporter provide you with a reproducible example. That way, you can be sure that it is a bug and not a user being too stupid and not admitting it.

    The real HTF is to get Joe Rnd User to provide you with said reproducible example. I would expect Joe to provide me with about half the variables I would need to reproduce the bug, and probably give me wrong values on 5% of those.

  • sweavo (unregistered) in reply to Anon Fred
    Anon Fred:
    T604:
    I don't understand how randomly generating the id would ever guarantee uniqueness.

    It doesn't; it just makes collisions a bit less likely.

    corrected your typo

  • (cs) in reply to Kaon
    Kaon:
    Vlad Patryshev:
    While fixing this is a good thing, wasting meeting time explaining to the incompetent subordinates how RNG works is an abuse of authority. See why. If you are in the coder's hat, act like a coder. Fix it, talk to the guy who was responsible for the bug, and keep it quiet. Or write a short unassuming memo. But please don't patronize. You may be a manager, but this does not mean you thusly become a super-coder, omniscient and omnipotent.

    I find it amusing that people actually refuse to learn, and refuse to be taught. If the dipwad developers had no clue, they deserved a lecture. It's not patronizing, it's pragmatics. That, or essentially "WTF did you during your CS education (whether formal or self-taught)"?!

    But the way the story is written, there was one dipwad developer (who the dev manager kept giving the problem back to) - but he gave the lecture to the entire development team. A really efficient way to patronise lots of people at once.

  • sweavo (unregistered)

    The real WTF is all the heated debate on here about whether or not it was the seed and how GUIDs may or may not be a useful way of guaranteeing uniqueness when every relational database provides, and depends upon, a way of making every inserted row unique.

    The problem was the coder did not know how to get the defined as unique ID just created by the database back out of the database session.

    It's encouraging the number of people who have said "one in a million is next Tuesday" but depressing the number of others who continue to think that "think of a number between 0 and 9, twice," is a good-enough solution to the problem of making an atomic insert-and-read-id!

  • (cs) in reply to sweavo
    sweavo:
    Anon Fred:
    T604:
    I don't understand how randomly generating the id would ever guarantee uniqueness.

    It doesn't; it just makes collisions a bit less likely.

    corrected your typo

    With a long enough ID you can make collistions arbitrarily unlikely. As in, more unlikely than the building the servers reside in being destroyed by a meteorite.

    In the real world, a theoretical certainty that a failure cannot happen is NOT more valuable than sufficiently small likelihood.

  • sweavo (unregistered) in reply to brazzy

    heh, yes I was being disingenuous there. I'm coming from a world of 16-bit hardware running up many millions of hours' unattended runtime, and failure consequences involving bent hardware and broken people. In my real world, the guaranteed is usually worth more than the highly unlikely.

  • T.T. (unregistered) in reply to MBC

    I agree.

    Who in his right mind would use random numbers to generate an ID??? Developers like that definitely did not have an education whatsoever, and I'm seeing more and more of those in the undustry. People that have had no education in Computer Sciences and think they can do it just as well. Yeah...Right! Ok, there are exceptions of course.

    CAPTCHA: Booyakasha

  • Alac Matthew (unregistered)

    We are a truly global product development firm that partners with software product companies ranging from start-ups to established ISVs to provide software product life cycle solutions. We have worked with more than 50 software product companies in various domains like Education, Healthcare, Retail and Finance. Our wide-ranging experience has enabled us to build a strong product environment within the company that remains unmatched in the industry. If you are looking for any software development services, let us know, click link and just fill up the form. Our experts will get back to you within 1 business day.

  • alan (unregistered) in reply to Salami

    Yes. Random values are predictable. More specifically, you can easily write statements that return false 99 % of time, but true 1 % of time.

    We use this property of random numbers to run occasional cleanup tasks and like. (Wipe data directories clean of old files.)

  • NeoMojo (unregistered) in reply to Alac Matthew
    Alac Matthew:
    We are a truly global product development firm that partners with software product companies ranging from start-ups to established ISVs to provide software product life cycle solutions...

    We also have eggs beans and spam

  • danio (unregistered) in reply to Some Engineer
    Some Engineer:
    Code reviews compliment unit tests

    Why test #7432a your hair looks especially nice today. Have you lost weight?

  • the real wtf fool (unregistered) in reply to RTFC
    RTFC:
    "the importance of reading the documentation"

    Now there's the real WTF. The documentation has nothing to do with the code. If you want to know what the code is doing, you read the code.

    All very well if you are working with C in linux. But as far as I know Microsoft don't publish the source for Rnd()?

  • (cs)

    RDN is a free magazine IF YOU LIVE IN THE US

    Believe me, there are people who don't live there.

  • (cs) in reply to T.T.
    T.T.:
    I agree.

    Who in his right mind would use random numbers to generate an ID??? Developers like that definitely did not have an education whatsoever

    Or they may be competent and doing the right thing (not in the given example, though). In a distributed system, performance considerations or architectural limitations or a requirement to allow offline operation may result in a random ID being your only choice. If it's done right, there's a hundred things that are more likely to go wrong and break your app than two large random numbers being identical.

Leave a comment on “Identity Crisis ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article