• trwtf is (unregistered)

    i can't decide what's less realistic: a company in the current era not jumping headfirst onto the ai bandwagon, safety be damned; or a company in the current era keeping employees around for 20+ years.

  • some guy (unregistered) in reply to trwtf is

    A friend of mine works in regulatory affairs for a medical device company. The company from the OP is not a software company, it's a "get the FDA to sign off" company, and from what I know, the clocks run differently in those.

  • (nodebb)

    I'm impressed there was still a guy you could ask about the limit, and get the explanation of why the limit was set to such value (which, while not strictly indispensable, is invaluable for determining whether it's safe to lift). A lot of places wish they had this knowledge.

  • (nodebb) in reply to trwtf is

    a company in the current era keeping employees around for 20+ years.

    I'm not shocked by that. I've been at my current employer for 17 years, and I'm at least six or seven years behind the longest-running still-there employees.

  • Vera (unregistered)

    Reminds me of a shaggy dog story I heard a while back.

    Little Jack was in the kitchen with his mom, and he noticed she cut the sausage for dinner in half before putting it in the pan. Out of curiosity, he asked why. "Oh," said his mom, "that's just how my mother always did it. Never really questioned it."

    So, next time his grandmother is around, little Jack asks why she always cut the sausage. "Hm... Didn't know that was odd, but it's just how my mother did it," she replied with a shrug.

    Now, thankfully both of them had their children pretty young, so great-grandma was still around. Next time the family went to visit her, of course little Jack asked about the whole sausage thing. To which great-grandma blinks and goes, "What? You're still using that stupidly small pan!?"

  • (nodebb) in reply to Vera

    Ah, this is one of those multiple versions of the same story type of story. The version I heard (and was hoping to see someone say it in the comments) was they would cook ham, cut the ends off, and when the child asked their mother about it, was told they have always done it that way because their mother did it. Don't remember if it was the grandmother who started in the version I heard, (I only heard it once over a decade ago) and the one who started just said the ham was too large to fit the pan the used to cook it, so they had to cut the ends off to make it fit.

    With how long ago it was, the fact the version I heard was more "child friendly" than your version at the end, it would not surprise me if it was part of a sermon at church.

  • (nodebb)

    I had the same reaction as Vera. A nicely told version of an apocryphal tale about the risks of following "tradition" without knowing why.

  • Monkey ladder (unregistered) in reply to miquelfire

    Sounds like a real world version of the five monkeys and a ladder experiment. Not to call anyone's relations a monkey.

  • Daniel Orner (github)

    The Jewish version of the story is that during Simchat Torah (when the congregation dances around the central lectern), one synagogue had the custom of always doing a ducking move when they passed the front side. The usual series of questions ensued and as it turned out, the synagogue in the old country where the founders originated had a wooden beam sticking out at that point and everyone had to duck to avoid it. But tradition is tradition, you know...

  • Joe (unregistered)

    I can kind of understand why these ports have requirements that nothing changes - no bug fixes or enhancements allowed. If you're going to allow more than 30 (more than 99) then you have to make sure the number is never stored or transmitted as a 2-digit string, for example. I know that sounds dumb but I'm sure I'm not the only one that has seen a seemingly harmless simple little change cause something unexpected to happen - use your imagination.

    That said, after the port is finished and stable, there's no reason not to go back and do those fixes/enhancements. No reason except it was working before so those are low priority so they won't get done until you have some time but that never happens due to a never-ending list of higher priorities. Does that sound about right?

  • Mr Bits (unregistered)

    Many requirements have ripple effects. During the 40 years that software has been alive in one form or another, it's likely that other parts of the software are based on the assumption that there are never more than 30 racks. Ferreting out all of these dependencies could be tedious. Or it could be a job for your AI.

  • PhysEd (unregistered)

    A physics simulation system I work on has some weird limits regarding the size of the input data. It has been ported to (relatively) modern C++, but when I asked about these limitations, I had to put on my Indiana Jones hat for the tomb dive.

    • This is how it was done with the Watcom C++ compiler in the late 90s
    • This is how the Pascal code was written
    • This is how the m68k assembly was written
    • This is how theFortran PDP11 code was written

    I couldn't go any farther than this. I wouldn't be surprised if there's some kind of abacus driven algorithm in there somewhere. And yes, these limitations are still in effect, despite many feature requests to increase them

  • (nodebb)

    I've always heard this as the "5 Monkeys" experiment. https://humanergy.com/change-is-hard-just-ask-monkeys/

  • Ms Bytes (unregistered)

    Right, I also thought that the author omitted the ending of this story, where Eric removed the requirement and everything exploded, because in 40 years all other parts of the system were built on the hard-coded assumption that there can never be more than 30 racks.

  • (author) in reply to PhysEd

    I once inherited software which derived requirements from the operation of a Burroughs mechanical calculator.

  • (nodebb)

    I am curious as to how this limit of 30 is actually enforced. The article is vague; is it enforced in the database? If so, how? If not, where?

  • (nodebb)

    Ms Bytes identifies the real problem. You can't know who's taken a dependency on your long-standing behavior, bugs and all. If your software only interacts with other software you control you could in theory, given the resources, verify there are no hidden dependencies on whatever behavior you're about to change.

    But if your software interacts with anything you don't control, whether you know that or not, chasing the unknown unwitting dependencies becomes not so difficult as to usually be impossible, but rather impossible in principal.

  • Brian (unregistered)

    Another thing to keep in mind is that in highly-regulated and compliance-based industries (I worked in military avionics for a while), the inertia is very heavy. Changing a requirement usually involves more time, paperwork, and general headaches than any reasonable person wants to deal with, so people tend to quickly get worn down and just stop asking questions.

  • scragar (unregistered)

    I have worked in medical software for the last 5 years, and we always keep specs around, even when they're obsolete(so spec 1234 was for the system as originally designed, then 2345 was for a rewrite to comply with some new standard that changed a bunch of stuff, every choice will be tagged with both specs and referenced all over even though 1234 is entirely superceded).

    We have a lot of limits on the system enforced in the spec justified as something like "Julie from compliance doesn't think we need to support more than 100" or "Jeff from the XYZ customer team says this should always be 17, we don't know what it does". Questioning stuff always takes ages, so for the most part no one questions it, the spec says it's right so unless someone raises a bug report that leads to an updated spec it's right.

  • dusoft (unregistered)

    Cargo cult FTW!

    CAPTCHA: Crosswalks

  • (nodebb) in reply to dpm

    I am curious as to how this limit of 30 is actually enforced. The article is vague;

    No it isn't. It's right there.

    Eric discovered that the database only allowed thirty racks. Add any more, it would just roll right back over to one

    So

    newid = lastid % 31 + 1;  // zero means no id and 31 is for FILE_NOT_FOUND

    Conveniently storable in five bits

    Addendum 2026-04-21 16:20: One line and I introduced a bug right there. Jesus H Christ.

    s/31/30/
  • (nodebb) in reply to trwtf is

    or a company in the current era keeping employees around for 20+ years.

    Working on my 19th year, one person who started before me is working on his 20th, and we have a staff member over 20yrs.

    We do have another one who has been with the company for almost 30yrs, but he left half way through and then came back, so doesn't really count.

  • (nodebb) in reply to jeremypnet

    With all due respect, jeremypnet, it can't be as simple as that, because if it was, this entire WTF would never have occurred because it would have been prevented by ONE SINGLE COMMENT. RIGHT NEXT TO THE TEST. ONE FSCKING COMMENT.

    newid = lastid + 1;  IF newid > 30 THEN newid = 1;    -- limited (by a race condition) purely so that it will fit on a floppy disk

Leave a comment on “Turning Thirty”

Log In or post as a guest

Replying to comment #695915:

Log Out

« Return to Article