• Davide (unregistered)

    I've been therebefore, I would just have added stupid tests for corner cases of the new UUID system.

  • Tobias Olofsson (unregistered)

    If the management only cares that the number of tests don´t decrease, just add more tests to get back to the old solutions count... Doesn´t have to be useable/functional ones if they only count the numbers...

  • Jaloopa (unregistered)

    I'd have just added in some pointless tests, maybe add some for unrelated parts of the codebase that are lacking coverage

  • Hanzito (unregistered)

    I've worked with kpiholics, people who likes their KPIs a bit too much, but this is a whole new level of failure.

  • Vera (unregistered)

    Goodheart's Law in action.

    Could add a bunch of fail-never tests, but that's just playing according to the rules of a fundamentally unfair game.

  • (nodebb)

    If the boss wants to play stupid games he ought to win stupid prizes. I'd leave the improvements as they are, Identify how many net LOC has been removed, then add that many new tests, each of which assert that `(const StupidGames = true) == (const StupidPrizes = true') and call it a day.

    If the boss also wants to code size of his project to also never decrease then I'd leave all the old code in there too. Just with a _old tacked onto the spots where necessary so nothing else will call it unless modified.

  • (nodebb)

    Hmmm....

    A UUID isa 128 bit number. If they were using a limited pool of ids before, that suggests the type was much more limited - 32 bit at best, probably fewer. I think I'd be concerned that Chops has made a far reaching change with perhaps unintended consequences. For example, if this was in C I would be concerned about comparisons of ids that ignored all but the lowest or highest 32 bits.

  • Jimbob (unregistered)

    You know, you don't have to delete code and its unit tests just because it's unused... update what the constructor calls and leave the old module and its unit tests in place.

  • Bogolese (unregistered)

    Hell, I would just generate a crap ton of unit tests to continue affirm the "uniqueness" of UUIDs. BMW tyres saved!

  • (nodebb)

    Makes you wonder what the old unit tests actually were. I mean, "give me 1000 ids and check that they are different" makes sense. But obviously no one thought to check what happens when they run out of ids so there was no test for that. Remove an id and check if you eventually get it again? Were there 40 other tests that checked performance or something?

  • Zatapatique (unregistered)

    Assert.AreEqual(Frist + Frist, Secnod);

    There, one extra test that will succeed gracefully!

  • (nodebb)

    Every comment left to future engineers contained a tone of apology.

    I would have tended towards bitter and cynical sarcasm myself, while keeping the "level" on the "good" side of "professionally acceptable". Yeah, it's a bit passive-aggressive, but ...

  • (nodebb)

    I hope the chap also took time to polish his resumé and moved on quickly...

    That said there's something puzzling in that story... How come this app has been "so stable for so long" only to fail with one major fatal core flaw all of a sudden? Something doesn't at up.

  • (nodebb)

    @Ralf: Their userbase finally grew enough that they were hitting the "All IDs in use" wall?

    Lotta ways for scale bugs to lie dormant until you get to their triggering scale.

  • (not a)[email protected](or is it) (unregistered)

    The correct solution after rolling back the changes would've been to add a unit test (because more is always better, remember) which would generate an error by causing a id overflow. Gary might want to have the unit test removed, because now there was an error... but that would decrease the number of unit tests....

  • Officer Johnny Holzkopf (unregistered) in reply to Steve_The_Cynic

    An idea would be to play the blame game according to the rules. So the comment could contain something like this: "As per explicit instruction of Gary, dated 2025-09-10, witnessed by Jim, Bob, Betsy and Sue, the rule NUMBERS GO UP is reflected in the following crappy code that doesn't work, but Gary insisted on keeping it, and he insisted that his orders shall not be questioned by normal thinking behaviour or negotiated in any way. Now you have fun with it. If you read this, I probably have successfully left this workplace." Written instructions are one thing, but comments and commit logs can also be considered a usable kind of CYA paper trail...

  • Maciej (unregistered)

    Frankly. Every dependency is a liability. Opens you up for supply chain attacks*. Adds up to what may eventually become dependency hell. Sounds like the pool algo was something simple enough to fix in reasonable time. I would probably just fix it and add unit tests for bugs discovered.

    *That's a real thing just this week it was discovered that account respcected author of JS libs was hijacked and added malware that would swap out crypto adresses.

  • John (unregistered)

    Prepend a timestamp to the uuid

  • (nodebb) in reply to Maciej

    Also let's not forget the disaster that was leftPad.

    There were a lot of arguments that nobody should pull from GitHub to production anyway, but tlnobody should write code without automated tests either, or have rules like "code counts can't decrease regardless the reason".

Leave a comment on “Myopic Focus”

Log In or post as a guest

Replying to comment #684156:

Log Out

« Return to Article