• Old Fart (unregistered)

    At some point the code will fail, and Mike's successor will be tasked with fixing it. He will find the problem and blame poor Mike for implementing obviously flawed logic. The new guy will be the hero, and Mike's reputation will be tarnished. I've seen this pattern play out over and over again. Sort of like the instructions on the bottle of Prell shampoo: "Wash. Rinse. Repeat"

  • Naomi (unregistered)

    Those who repeat truisms mindlessly are doomed to misapply them. If I'm understanding this correctly the appropriate regex is four characters long (^\d+) and easily commented even for the complete neophyte in the subject ("one or more (+) digits (\d) at the beginning (^) of the string").

    (If our protagonist didn't think to tell their boss about the 2020 issue in particular, then they would be TRWTF, but I'm inclined to assume that's just the editor not wanting to give away the ending.)

  • (nodebb) in reply to Naomi

    More likely the protagonist didn't want to have a discussion with the boss of why he didn't do what was asked, just copy/paste and tweak.

    But of course even the approach itself is fundamentally flawed. Each version has a list of features it supports, and the question they are trying to answer is not "which version is it?" but "does it support feature X?".

    That is, we should not ask, "Is Creator at least version A? Yes, OK it supports features X and Y and Z but not W," but rather, "Where is the feature support for version A? OK, got it, does it include feature Y? OK, yes, good, enable support here for feature Y."

    Then you have a cross-version resource that contains each version's feature set information, and look up the version you find in there.

  • Hal (unregistered)

    This seems like a bad way to handle this in general. Version schemes change from time to time. Sometime products get merged into to other products and than which version number do you keep?

    Seems like they really should implement something like getCapabilities() in Creator.

  • Anon (unregistered)

    Everybody knows how to solve this problem, MS, for example, gave Windows 10 a 10 instead of a 9 for a reason.

    I just want to know if the Analyzer 2020 version is called 19.1, 2a.0 or 21.-1

  • Scott (unregistered)

    I was thinking along the lines of Steve's comment. Instead of version string parsing, have a secondary piece of information which tells you you're on <auto-incrementing version number>, and new features can just check >= that.

    I like the database idea even better, because then a UI can be developed to expose that. "You're on v X, which has these features. But, look what cool stuff would be available on v Y! (For only a small upgrade fee).

  • Michael (unregistered) in reply to Old Fart

    Mike has hopefully left a comment in his 13 release pointing out the slow train crash about to happen.

  • MiserableOldGit (unregistered)

    Regex seems a distraction here ... the string handling is over simplified leading to a potential future bug, that could happen with their logic, RegExes or any other implementation. One just hopes the testing would flush it out in the first release of 2020. It's an easy fix, with or without a RegEx, but if using a different approach means bundling up the whole routine into a magic black box into which you feed the version string and out pops "some flags" that will be a whole headache of WTFery in the future.

    How do we know a predecessor didn't highlight the line was a quick scruffy hack in 2010 and got told by a boss at the time "The product has been around x years already, we'll be doing a ground up rewrite before the next decade is out, stop over-complicating things we need to ship!"? I'd have asked that, heard that, and put a comment there which someone else would have deleted ... at, oh, most places I've been at. Sometimes I've quietly fixed it, others I just thought "fuck 'em!".

  • Brian (unregistered)

    var majorVersion = Int.Parse(versionStr.Substring(0, versionStr.IndexOf('.'));

    Simple, reusable, no regexes. Sure, it's not the most absolutely efficient way to do things, but c'mon, you're parsing a version string, it's not exactly hammering the CPU.

  • Stephen Cleary (unregistered)

    // This will break in 2020, but $(boss) won't let me fix it.

  • YR (unregistered)

    "If our protagonist didn't think to tell their boss about the 2020 issue in particular, then they would be TRWTF" The way the story was told, protagonist attempted to tell (pointy haired) boss that there was an issue, and was rebuffed. Presumably, protagonist had too much pride to get down on his hands and knees and follow around said (point haired) boss indefinitely until he was gracious enough to listen to a lowly peon.

    “Like, I mean, really problems- the way it-” His boss cut him off and spoke very slowly.

  • v20.wtf (unregistered)

    TRWTF is not just parsing the version number out of the string as a number, at least for the primary version, like Brian suggests. You can wrap this in a Version class if you want (particularly in .net where you can use operator overloading on > to make the check look nice) but even just getting a number and doing numeric comparisons is fine.

  • Solw Purpose Of Visit (unregistered) in reply to Naomi

    Ah, but you misunderstand the true genius of Cargo Cult Management. Just smart enough to be able to put his shoes and socks on the right way round, and with just enough tech savvy to have heard of the "Some people, when they have a problem …" Zawinski quote.

    But still utterly incompetent.

    "It uses string slicing, which performs way better than regex anyway."

    What sort of demented ignoramus would care about performance, when taking a ten character byte sequence apart? Unless thoroughly anonymised (and I doubt this), the version string seems to be utterly straightforward. Worry about correctness first and fire anybody who even thinks aloud about "performance."

    (Or alternatively be a prick like me, and rewrite the whole thing in the assembler of your choice.)

  • BeenHereSeenThat (unregistered)

    About 1993, while working on porting company code written on a VAX to the Alpha and on the VMS operting system we had the foresight to test some aspects that handled dates in the year 2000 (7 years in the future). Can't say I remember what we found, but I was amused to learn there was some issue in VMS circa 2017.

    Second story, early this year ended up some home grown utility script that had been coded in 2010 or 2011 that stopped working because the last two digits of the year were no longer 1x. Never knew Micheal personally, but based on his code and the time that his boss-- took me aside after I sent an e-mail to Michael but addressed it Mike - yup, that mattered too much- I was not surprised to find this bug.

  • ooOOooGa (unregistered) in reply to Naomi

    I did in fact flag the 2020 problem with the version 11.0 parsing function. I even wrote a ticket for it.

    But with 5 of these functions in existence at the time I left, and with 6 more likely having been written since, I expect that there are still several more delayed foot-guns ticking away.

  • Raj (unregistered) in reply to Old Fart

    Reminds me of the reason I stopped putting my username in those flower boxes above functions. People change the content of the function but not the comment, or even worse they copy-paste code including the comment in another file, and then you're forever responsible for code you didn't write.

    For instance I've had people ask me "why didn't you check for null in your code in Project X" even though I switched to a different team years before the old team started to work on Project X, and I never made a single commit in that project.

  • gidds (unregistered)

    All the tests are green? That gives you an obvious solution! Just add/update a test which checks for version 20. Or 21. Or, better still, a random version number.

    As ordered, that doesn't touch the code for any of those routines — but it's likely to lead to them being fixed, or at least to make people properly aware of the problem. It'll also make life easier for whoever has to fix them. And, as a bonus, it'll ensure they don't get broken again in future!

  • shcode (unregistered)

    ... why the hell wouldn't you split the string at the dot, cast the first part into a number, and compare those...? why would you do this "what's my second character" nonsense at all?

  • gnasher729 (unregistered)

    Some years ago when MacOS 10.4.10 and 10.4.11 were released, several apps broke because their version check figured out that this was a version earlier than 10.4.2. Don't use string comparisons for numbers.

  • v20.wtf (unregistered) in reply to gidds

    That gives you an obvious solution! Just add/update a test which checks for version 20. Or 21.

    Which 'breaks the build' and now you're responsible (or just get shouted at for breaking the build).

  • Naomi (unregistered) in reply to shcode

    If I had to guess, either they wanted to "optimize" the check ("Why would I drag a whole parser into this when I can just do a length check and handle the special case manually? That's got to be more efficient, which is absolutely essential in a function that gets called once on startup!") or they were afraid of an exception ("I don't want to crash the whole program just because a version number that absolutely must be generated correctly was generated incorrectly!").

  • Calli Arcale (unregistered) in reply to Old Fart

    Which is precisely why we see so many WTF comments in code; people making a desperate attempt to regain some of their dignity after having to commit atrocities like this to the repository.

  • (nodebb) in reply to BeenHereSeenThat

    I have worked with VMS as a software developer for years, in the 90s and very early 2000s, but I have never heard of a 2017 problem. There was (is?) however a year 2038 problem: https://en.wikipedia.org/wiki/Year_2038_problem.

Leave a comment on “The Time-Delay Footgun”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article