back to article Yeah, we'll just take that first network handshake. What could possibly go wrong?

Brickbats and bouquets are the way of things in the world of IT. Consider today's Who, Me? entry where our hero nearly fell on his sword when a bug bounty might have been more appropriate. Our story goes back to the mid 2000s, when "Bill" (not his name) was working in the information security department of a large retailer. " …

  1. Pete 2 Silver badge

    The guiding principle

    > how an inappropriate packet would be dealt with. "They (rather smugly, I thought) replied that we should not allow that."

    Which does seem to be how pretty much all code gets written. Whether in 1980 or 2020, very little has changed in the rush to get product out the door ASAP. Following the four stages of development:

    1.) does it compile

    2.) does it run (not core-dump)

    3.) does it produce the expected results from the expected inputs

    4.) does it consume less resources than what a medium-sized country might have available

    After that, it's golden. Send the customer the bill!

    1. Korev Silver badge
      Joke

      Re: The guiding principle

      > Send the customer the bill!

      In this case they sent Bill and the AS/400s fell over

    2. My-Handle Silver badge

      Re: The guiding principle

      I got that lesson in sanitising my inputs very early on in my career.

      Was working with Google's Search Console, getting a list of the top 10 search keywords used to find a client's website. Google provided it as a comma-delimited field in a JSON object. My code, confident that Google knew what it was doing, split the string on the comma and cycled through the array up to 10 times.

      Except that one time when Google bloody sent through a keyword with a comma at the end of it, thus chucking an extra, empty element into the array that my software proceeded to choke on. You'd have thought that a company the size of Google would have thought to strip formatting characters out of the data being formatted, but no. Likewise, I was a dumb for not considering that I could get either crap or no data back and writing tolerant code for it.

      1. Howard Sway Silver badge

        Re: You'd have thought that a company the size of Google would have thought...

        There's your mistake.

        You'd have thought that a company the size of Microsoft would have thought...

        You'd have thought that a company the size of IBM would have thought...

        You'd have thought that a company the size of Oracle would have thought...

        Nope. They're all just as human as everyone else, the idea that their code and system design must be of some mystical higher order than yours will eventually be disproved by something that makes your brain hurt with its awfulness.

        1. My-Handle Silver badge

          Re: You'd have thought that a company the size of Google would have thought...

          Yep, definitely was my mistake. That was the lesson learned.

          My only defense there was that I had only just started down the path to becoming a software developer. I was trying to cobble together a program in VBA (that'll invite the downvotes :D) to help out my team at the time.

          Some things you only learn by making the mistake.

          1. Doctor Syntax Silver badge

            Re: You'd have thought that a company the size of Google would have thought...

            "Some things you only learn by making the mistake."

            Preferably someone else's mistake.

        2. Stuart Castle Silver badge

          Re: You'd have thought that a company the size of Google would have thought...

          You can assume competence all you like, but while the likes of Google, IBM etc may make reasonable efforts to ensure the data sent to you is correct and correctly formatted, when it comes down to basics, all they care about is that their arse is covered in the event they do send wrong or incorrectly formatted data.

          1. Terry 6 Silver badge

            Re: You'd have thought that a company the size of Google would have thought...

            And I'd assume that cost control is more important to them than quality control.

        3. A Nother Handle
          Holmes

          Re: You'd have thought that a company the size of Google would have thought...

          It's the law of large numbers innit? They produce so many products, features and lines of code (all ultimately created by fallible humans) that they're sure to contain egregious errors. The only uncertainty is will your workflow be disrupted by them?

        4. EnviableOne Silver badge

          Re: You'd have thought that a company the size of Google would have thought...

          yeah but they have the pennies to pay for someone to catch these issues, most of us don't.

          The problem is they choose to give those pennies to CXOs or shareholders rather than spend them on making stuff that, you know, works.

          Also chances are the code comes from some of us that didn't have the bandwidth to deal with the bugs, but contributed it to some OSS or forum to prove a point.

      2. Kubla Cant Silver badge

        Re: The guiding principle

        You'd have thought that a company the size of Google would have thought to strip formatting characters out of the data being formatted, but no.

        A list of top 10 search keywords might terminate a comma if there are only 9 keywords. If no keywords, it might be all commas.

        The thing that's really weird is sending a delimited list in a JSON response, when an array would be appropriate.

        1. My-Handle Silver badge

          Re: The guiding principle

          I could be wrong on the detail, it was getting on for a decade ago. I barely knew what JSON was at the time. I've not seen anything like that from Google since, I admit.

          1. JamesTGrant

            Re: The guiding principle

            I remember first hearing about ‘Jason documents’ - there was only one Jason in R&D at the time and I thought it very odd that all of a sudden people were parsing Jason’s documents, he suddenly seemed very prolific!

            1. Anonymous Coward
              Anonymous Coward

              Re: The guiding principle

              There was a chap at my school called Jason Parsing. He was a pain in the arse. It should have been funny, but json was years in the future, and last i heard, he was a motorbike mechanic so has probably never been in a situation where it would be.

      3. aerogems Silver badge

        Re: The guiding principle

        At a previous job I ended up having to deal with non-breaking spaces getting left at the end of text strings that I had to create a quick macro to get rid of them. Otherwise, the core SAP system would have no problems with it, but it would break BI reports. Apparently even at a company the size of SAP, specializing in making enterprise grade software, no one ever thought that maybe an HTML based reporting system would have trouble dealing with non-breaking spaces. Or they just didn't care.

        1. J.G.Harston Silver badge

          Re: The guiding principle

          Every few weeks I have to do a clean-up of our Active Directory system because people have left trailing spaces in various fields and it breaks the reporting system that takes exports from it. You'd think either one or both would strip leading/trailing spaces on entry/import.

          1. Mike007

            Re: Trailing spaces

            We have Mac users who use SharePoint/OneDrive. MacOS permits a space at the end of the filename, which can only be seen by right clicking and selecting rename. SharePoint/OneDrive doesn't like these files and refused to sync them.

            Nearly every time I check a users device I see failed sync items, and it is nearly always a space at the end of the file name. Except when the filename contains a \ which apparently macos also allows...

            1. gnasher729 Silver badge

              Re: Trailing spaces

              MacOS x allows any valid unicode code point in utf-8 format, except nul and slash (on its own drives, network

              drives have different rules).

              1. Irony Deficient Silver badge

                MacOS x allows any valid unicode code point in utf-8 format, except nul and slash …

                … (on its own drives, network drives have different rules).

                Well, it depends. For example, HFS+ volumes use Apple’s own non-standard variant of Unicode Normalization Form D for some codepoint ranges in filenames, so a file with the name “Ω” (the Greek letter, U+03A9) can’t be opened by referring to it with the name “Ω” (the ohm sign, U+2126), despite U+03A9 being the standard decomposed form of U+2126. However, opening a file named “é” (two characters: U+0065 U+0301) by referring to it with the name “é” (one character: U+00E9) succeeds, and trying to create a file with the name U+00E9 will actually create a file named U+0065 U+0301, its decomposed equivalent.

        2. Anonymous Coward
          Anonymous Coward

          Re: The guiding principle

          "Or they just didn't care."

          Or they saw it as an opportunity to sell you a custom upgrade to do "enhanced data manipulation/pre-sanitization for external reporting" deliverable in 9 months after receipt of a large purchase order.

          (Never dealt directly with SAP, but I've dealt with similar companies)

      4. My-Handle Silver badge

        Re: The guiding principle

        2 downvotes already... harsh crowd today.

    3. Loyal Commenter Silver badge

      Re: The guiding principle

      This highlights the difference between a programmer, a developer, and a software engineer.

      A programmer writes some lines of code that give the desired result.

      A developer writes some lines of code that give the desired result, and can be understood by someone else.

      A software engineer does the above, but also writes the other 90% of the code to sanitise the inputs and handle error conditions.

      As for code efficiency? Well, Donald Knuth himself wrote that, "premature optimization is the root of all programming evil". Whilst we should be aiming to avoid egregious resource waste, we shouldn't be looking to make efficiency gains where the bottlenecks aren't. There's no point making your code super CPU-efficient if what it is doing is disk-bound, for example. At the same time, the habit some developers seem to have for pulling in hundreds of JavaScript libraries to solve a simple problem is a bit of a red flag...

      1. Killfalcon

        Re: The guiding principle

        And yet, people to this day make Tetris games that overheat CPUs literally thousands of times faster than the original gameboy.

        Premature optimisation is bad, but inevitably anything left to the end of the project is cut for time.

        1. heyrick Silver badge

          Re: The guiding principle

          Gameboy - calls a library function that pokes screen memory.

          Modern - calls a function that talks to a framework, which talks to a framework, which creates an object, and talks to a framework, which calls a library function, in another framework, which calls another library function, in a system library, which calls a function, which calls a function, which calls a function, in a driver, which calls a function, which calls a function, which sets a mutex, which gets a hardware address, which changes a single pixel on the screen, which clears the mutex, which returns a result, which returns a result, which returns a result, which returns a result, which returns a result, which returns a result, which returns a result, which returns a result, which destroys the object, which returns a result, which returns a result, which returns a result. Easy.

          1. Strahd Ivarius Silver badge
            Devil

            Re: The guiding principle

            and the result is either True, False, or FileNotFound

            1. theOtherJT

              Re: The guiding principle

              The number of systems I've encountered that treat booleans as "True", "False" or "undefined" drives me absolutely nuts. It's not a god damned bool then, is it? That "undefined" should be an error condition. /rage.

              1. Jou (Mxyzptlk) Silver badge

                Re: The guiding principle

                The result is $true, $false or $null. Be prepared.

                1. Must contain letters

                  Re: The guiding principle

                  best then to just treat all boolean functions like a teenager.

                  Q: Do you want a vanilla ice cream?

                  A: Yes | No | Sulky silence | I want a burger

                  1. midgepad Bronze badge

                    Useful, needs naming

                    Yes,no, not saying, essay about other desires/why that's a silly question.

                    Teenean?

                  2. Doctor Syntax Silver badge

                    Re: The guiding principle

                    It's not just teenagers. If I ask SWMBO something the answer is quite likely to be something unrelated and very likely an unrelated question.

                2. heyrick Silver badge

                  Re: The guiding principle

                  The three logical responses in English: Yes, No, and Mu.

                  Because there are times when the correct answer is neither affirmative nor negative.

              2. yetanotheraoc Silver badge

                Re: The guiding principle

                True Booleans (ha!) are useful. True/false/undefined, while not "Boolean", are also useful. It seems your rage is spent on people not using a correct label? We need a new term for true/false/undefined. I nominate Booolean.

                1. Irony Deficient Silver badge

                  We need a new term for true/false/undefined.

                  Given that the terms “Boolean” and “bool” were named for George Boole, clearer terms for three-valued logic might be “Kleenean” and “kleen”, after Stephen Kleene. (In both “Kleenean” and “kleen”, the “ee” would be pronounced in the German/Dutch fashion, to rhyme “kleen” with English “lane”.)

                  1. heyrick Silver badge

                    Re: We need a new term for true/false/undefined.

                    No no no! We haven't sorted GIF out yet! What will we do with a clean type?

                    1. Irony Deficient Silver badge

                      We haven’t sorted GIF out yet!

                      What will we do with a clean type?

                      Spell it with a “c”, of course.

                      (I tried to get ahead of any pronunciation confusion with “Kleenean” and “kleen” by including the proper pronunciation of “ee” in Kleene in my comment above.)

                  2. Stevie

                    Rhyme "Kleen" with "Lane"

                    Then spell it the way you want it pronounced!

                    Gordon Bennet, there can be no more worthwhile project than to get rid of all the clixby mispronounceable names infesting IT today.

                    1. Irony Deficient Silver badge

                      Then spell it the way you want it pronounced!

                      They already are — the spelling and pronunciation of “Kleenean” and “kleen” reflect the spelling and pronunciation of the surname Kleene, from which they were directly derived.

                2. nintendoeats Silver badge

                  Re: The guiding principle

                  std::optional<bool> of course.

                3. Anonymous Custard Silver badge
                  Trollface

                  Re: The guiding principle

                  I nominate Booolean

                  Wouldn't the three states there be either true, false or spookily scary?

                  Or at least the extranious one would make you jump in fright...

                4. EnviableOne Silver badge

                  Re: The guiding principle

                  Surely this is a Qbit.

                  1,0 or something

                  maybe a QuantumBoolean or Qlean

                  1. Stevie

                    Re: maybe a QuantumBoolean or Qlean

                    Presumably pronounced "clone".

                  2. C R Mudgeon

                    Re: The guiding principle

                    "Surely this is a Qbit."

                    Almost surely it's not. I'd hazard a guess that the vast majority of people who write code have never encountered a qubit, while most of us have encountered yes/no/don't-know situations.

                    Please don't conflate the general idea of yes/no/don't-know variables with one (currently rather esoteric) implementation of said idea. That way lies madness.

                5. C R Mudgeon

                  Re: The guiding principle

                  Hardware people already have an excellent word: "tristate".

              3. Redact Ted

                Re: The guiding principle

                Ha, just had to work through "working as designed" by our vendor who decided to handle a shared 'null' opt in flag in opposite ways on two of their own products.

                Their response? "Yes, it would have been nice if these had been implemented consistently."

              4. Doctor Syntax Silver badge

                Re: The guiding principle

                "True", "False" or "undefined" drives me absolutely nuts.

                But if the real value cannot be determined you either end up with 3 possible values including undefined or demand a plain unvarnished Boolean you end up with 4 possible values:

                true,

                false,

                true but might be false because you demanded something and you've no way of telling the difference between this and true

                false but may be true because you demanded something and you've no way of telling the difference between this and false.

                1. J.G.Harston Silver badge

                  Re: The guiding principle

                  You need a 2-bit bitfield. bit X=0 this is a bool, value in bit Y; bit X=1 this is not a bool, bit Y for extension.

                  I've actually used something like this in real work: a function returns -1,0,1. returning false and the caller doesn't do anything, returning not-false and the caller does do something, the something determined by what sort of not-false. Usually a: do this? Yes/No/Stop-asking-me prompt.

                  1. Loyal Commenter Silver badge

                    Re: The guiding principle

                    We have enums for that; we define "this" as 0, "that" as 1, "the other" as 2, and lo-and-behold, if we decide we need a fourth value, we can add it to the enum. Just make sure you are using the same enum everywhere, not defining it multiple times, eh?

                    Nullable types have their uses too. A nullable bool can have values of true, false, and "fucked if I know". If you start relying on that third value to mean something specific other than unknown then you're in trouble. IMHO the closest to the correct implementation of a null value is in SQL, where a null value for a nulalble bool does not equal true, it does not equal false, and it also does not equal another null value. Languages where a null value is treated as false (JavaScript, I'm looking at you), or, even worse, as true, are just wrong.

                    The problems arise, of course, where one person uses null to mean "unknown", and another uses it to mean "not chosen", or "not defined" which are (subtly) semantically different.

                    In most cases, you will not be worried about the storage size of a boolean (or nullable boolean) vs the size of a machine word, so there really is no reason (usually) not to use an enum in any code that doesn't generate and consume that value straight away, where the purpose of that nullability should be apparent, because we all write well-crafted code, right?

                    1. heyrick Silver badge

                      Re: The guiding principle

                      JavaScript probably copied it from C, not realising that the definition of NULL in C is a null pointer (probably defined as something like ((void *)0)).

                      It's supposed to be used for testing returned addresses, like malloc() would hand back. It's not a third logical value. NULL equals FALSE because in C, non-zero is TRUE, zero is FALSE.

                      The compiler will accept it, but "if (value == FALSE)" and "if (value == NULL)" are two different things that happen to have the same behaviour. The first expands to "if (value == 0)" (probably what you meant) while the second is "if (value == ((void *)0))" (only what you meant if checking pointers).

                      Yes, if you need to return a "fucked if I know" option, then you shouldn't be using a bool. Or (looks at a lot of modern software) ignore the problem until there's an unrecoverable crash, then blame the user's machine.

                      1. Michael Wojcik Silver badge

                        Re: The guiding principle

                        the definition of NULL in C is a null pointer

                        That's not correct. ISO 9899 requires that NULL be an object-like macro which evaluates to a null pointer constant, or a null pointer constant cast to type void*. A null pointer constant is any constant integer expression which evaluates to 0.

                        That means the following is a conforming definition of NULL, for example:

                        #define NULL '\0'

                        A null pointer is an r-value of object-pointer type (i.e. a pointer, but not a function pointer), containing the implementation's representation of the null-pointer value (which need not be all-bits-zero, though that's what it is for the vast majority of implementations).

                        So NULL and a null pointer are quite different things in the C language, even if the former evaluates to an instance of the latter in appropriate contexts.

                      2. Loyal Commenter Silver badge

                        Re: The guiding principle

                        The problem here is that JavaScript, an untyped scripting language, is copying stuff from C, a strongly typed compiled language.

                        TBH, the idea of using 0 = false, and any non-zero-value = true should have set alarm bells ringing in the first place. Two meanings (true/false) should equate to two values (1/0) and be stored in a type that is represented by one bit.

                        JavaScript took this moment of insanity, thought "hey, this is neat" and went on to say "what if we...", so we have a situation where an empty string is "false", the string containing the word false is "true", and the number 0 is false... usually... unless it's the result of an arithmetic calculation that has a floating point rounding error in it, and your value you thought was 0 is actually 0.000000000000043 or something like that.

                        At some point the various people who were all coming up with their own slightly different JavaScript interpretations should have stopped, and said, "hey guys, I think we might have fucked up here".

            2. stiine Silver badge
              Mushroom

              Re: The guiding principle

              You must be young. The earlier version of that was Network Error. Fucking Microsoft...

            3. anothercynic Silver badge

              Re: The guiding principle

              Or 'Nothing'.

          2. Pete 2 Silver badge

            Re: The guiding principle @heyrick

            > which calls a library function that the author subtly changes for no good reason except to keep their Github current

            > which returns a result that the coder ignores

            1. Doctor Syntax Silver badge

              Re: The guiding principle @heyrick

              Github? Make that Gitlab, at least for a day or so before they changed their mind their mind was changed for them by public resonse.

            2. Anonymous Coward
              Anonymous Coward

              Re: The guiding principle @heyrick

              for all return code tests

              if return <> 0

              return = 0

        2. Loyal Commenter Silver badge

          Re: The guiding principle

          It uses a lot of processing power and network resources to slurp all the data off your phone and send it to some advertising profiler, or worse, and also to download lots of loud video ads in the background. And that's the point of 99.9% of "free" games.

    4. aerogems Silver badge

      Re: The guiding principle

      This brings back memories of a COBOL class I had to take. Half the grade for any given assignment was whether or not the program compiled. So, once or twice I didn't have time to figure out why the program wasn't working properly, but it compiled. If you tried to execute it, however, it would immediately lock up the interpreter app (a 16-bit Windows app, and this was in the days of XP).

      So, technically I met the first two conditions.

      1. stiine Silver badge
        Facepalm

        Re: The guiding principle

        I wasn't as smart as you. In CSS460, the final project was an assembler that had to generate code for a defined set of input. Mine would not handle 2 of the cases...so I didn't turn it in. I got an Incomplete that was turned into an F. Talking to the intructor later, as I also was an employee of the uni, it turns out that my 2 failed cases (if true...) would have earned me one of the best grades in the class because most of the rest of the projects didn't even do that well... I have to admit that 30 years later I'm still a perfectionist.

        1. Michael Wojcik Silver badge

          Re: The guiding principle

          When I taught university classes I always stressed to my students that they should turn in work, even if it was incomplete or broken. Even better, turn it in multiple times until the deadline is reached. (Generally I'd even give credit for work after the deadline, if you'd shown me you were making an honest effort before it.) Show me, in class and office visits, what you have, what works, what doesn't. Ask questions.

          Show me your progress. The point is to learn, not to create toy artifacts.

          1. C R Mudgeon

            Re: The guiding principle

            "Generally I'd even give credit for work after the deadline"

            The rule used by many of my CS profs was: submit it N days late, lose 2^N percent of your mark. So, a day late? Yeah, whatever. A week late? Don't even bother.

          2. anothercynic Silver badge

            Re: The guiding principle

            I cannot support this enough - This is what I used to tell the students I used to supervise (as second/third-year student supervisor) in class too! I said "turn it in, even if it doesn't work, because I can probably look at it and see what you *tried* to achieve, and maybe it's just a small thing that broke it/would fix it".

            I marked things like that too. I'd then tell them on their paper what the problem was and how to fix it (and COBOL was an utter b**** back then).

            Of course, I did also spot people who would copy someone else's work (by opening Sidekick, where most people wrote their code, and then saving their own copy onto their floppy disk). Because this was an endemic problem, the first of the many identical copies I'd spot would get full marks, the one(s) after, half. If the original coder was one of the latter - Tough.

            Our instructions were always "once your assignment works, and you've printed it, reboot your workstation!" so Sidekick would get nuked, and along with it any resident copies of their assignment.

      2. MrBanana Silver badge

        Re: The guiding principle

        COBOL was my University hell. I didn't even get my course test code to compile. I spent hours trying to figure out what ERR: 3657 at line 68, or some such was. And then the next error, and the next. I gave up. I handed it in and the lecturer couldn't figure it out either. I got a pass, more than can be said for the COBOL compiler.

        And then I got a real job. SQL database programming. "We have an embedded SQL language for COBOL", they said. No, just no.

        1. anothercynic Silver badge

          Re: The guiding principle

          Bless you. The primary reason I recall students would get errors with was not rigorously checking that they didn't exceed the 72 character boundary (73-80 were for 'binary'), or accidentally putting things in columns 8-11 that didn't belong there.

          Even a trailing space at the end of a line mattered for the 73-80 boundary and wreaked havoc with the binary code. You won't believe how many students had that problem.

      3. Stevie

        Re: The guiding principle

        "Interpreter App?"

        So obviously not really compiled then, and even more obviously, not real Cobol, but some silly compiles-to-C (or worse: compiles-to-Java) toy computer nonsense.

        @ACOB,CRYPES lads, with special option 7 for those times your team can't figure out why the damn thing guard modes unless MONITOR ALL is compiled in.

        Now: Get off my Zen sand garden c/w fishing gnome!

    5. tekHedd

      As a disciplined, experienced developer...

      I really want to downvote this. But I can't because it's true.

      #sigh

    6. MrBanana Silver badge

      Re: The guiding principle

      You had me at 1.

    7. JamesTGrant
      Joke

      Re: The guiding principle

      Core dump? Crumbs, that’d be bad - you’ll be wanting to suppress that!!

      If a tree falls in the forest….

    8. swm Silver badge

      Re: The guiding principle

      When we were developing time sharing in the 1960's on a main frame we discovered a computer instruction that would hang the computer dead even in slave mode. On complaining we were told to run interpretive when we were about to run code with that computer instruction.

      No amount of protesting worked until we started crashing their computers.

    9. big_D Silver badge
      Mushroom

      Re: The guiding principle

      We always had "comprehensive" testing, there were entire suites of tests that put illegal inputs into the programs - from simple out-of-bounds checks to alpha in numeric, invalid dates, no input at all, too much input (64KB+ strings into numeric fields, for example. As well as more complex tests, such as SQL Injection.

      Did it cover everything? Probably not, but it covered the main problem areas at least.

      I did do a security test for a high street retailer that wanted to take their shop online in 2002. I came across a SQL Injection vulnerability, so I went through the code and located a few hundred places where that would crop up and documented the problems and how to fix them...

      The client wasn't interested - after all, what could you possibly do with a SQL Injection in a shop database? Pulling out the user list wasn't enough, pulling the credit card details out of the test system also wasn't enough, it wasn't a priority... In the end, I did a DROP DATABASE; from the username field... THAT got their attention!

      Sometime going nuclear is the only option, to get people's attention.

      1. G.Y.

        tables Re: The guiding principle

        cf. Johnny Tables

        1. big_D Silver badge

          Re: tables The guiding principle

          Johnny is my quite, shy little brother! :-D

  2. Evil Auditor Silver badge

    ...before we had implemented much of a change management system...

    There, that's the problem. Although in all fairness, sometimes it's a bit tricky to reproduce a full production load in a test environment and some problems may remain concealed during test...

    1. MisterHappy
      Facepalm

      You mean Change Enablement don't you?

      Yes I think it's ridiculous too but apparently it's not Change Management anymore.

      Icon for the whole "We are not managing but we are enabling" wank.

      1. Anonymous Coward
        Anonymous Coward

        Re: You mean Change Enablement don't you?

        Managing? In our place they're not managing, they're barely coping...

    2. Nightops25

      Change control processes for most organizations only come in after there is already a demonstrated need for them to be in place. Like the old saying "safety rules are written in blood." These controls are in place because someone didn't have the foresight to put them in before they were needed.

      1. bregister

        I saw a variation of that phrase in a book about aircraft safety "checklists are written in blood".

    3. phuzz Silver badge

      Part of a 'Change Management System' is managing people. In the article's case,a "phone number to call if something weird happens" should have been available, or even just instructions on how to stop the new process.

      Hope for success, but always have a plan for failure.

  3. ColinPa Silver badge

    Why has this software got zero defects?

    30 years ago I remember hearing about some software had to be installed - mandated by the country's government. It had close to 0 defects and very few fixes, and was held up as a good example of how software can be.

    Until the government started doing audits to check it was installed, and insisted that the software be >activated< rather that just installed.

    Activating the software killed performance, and the software had so many problems, the auditors agreed it could be turned off!

    When the auditors checked that their own government's software was activated. they got told the same thing (no way are we running with this).

  4. UCAP Silver badge

    While reading this ...

    ... the thought crossed my mind, then came back and had a party: "There but from the grace of <insert deity name here> goes I"

  5. wolfetone Silver badge
    Pint

    And Bill kept his job.

    That's the main thing.

    1. elkster88
      Trollface

      Re: And Bill kept his job.

      Never forget: the most important product your company makes is your paycheck.

      1. lepermime

        Re: And Bill kept his job.

        But weee're a faaaamiiillyyy. I don't want to hear you're only here for the moneyyyyy.

        1. Loyal Commenter Silver badge

          Re: And Bill kept his job.

          Because abusive relationships can be employment relationships too...

  6. Kaley endocytic

    Coincidence

    In the 1990's I was working at the Financial Times, writing software for their page-makeup system on an Mac. One day we deployed some new code, and immediately the pages started drawing wrong, missing text, missing some read throughs, missing graphics. Of course the senior managers blamed our newly deployed software, but I couldn't find any problems with it. In the end they called a meeting of the software and network teams to find the issue. After some investigation, turns out there was a broken bridge on their network, which was dropping or corrupting packets, nothing to do with my changes at all.

    1. A.P. Veening Silver badge

      Re: Coincidence

      Wow, it wasn't DNS ;)

      1. TimMaher Silver badge
        Happy

        Re: DNS

        Or BGP?

    2. Ace2 Bronze badge

      Re: Coincidence

      A few years ago I ordered a new HDTV antenna. I hooked it up, then tried it - but hardly got any channels. A lot of troubleshooting later, I found a newspaper article saying that *that exact day* was the cutover date to rearrange the local frequencies, and I needed to tell the TV to do a full rescan.

  7. Stuart Castle Silver badge

    Posted this before, but I used to manage a Windows Media Server, with hundreds of potential streamers, all needing "accounts" on it. Well, Active Directory took care of the accounts, I just needed to create urls on the server for each user.

    Obviously, the GUI was out, because that would have been far too cumbersome, and I didn't get notifications of new accounts anyway. Microsoft didn't have a method for automating this process either, at least not one I could find or had access to.

    So, I found a registry hack. You just created a key for each user with the value pointing to their user area. I wrote a small C++ application that automated this, and certain other maintenance functions, as well as notifying me if it could not see the server. It also had a function to check AD for any new accounts and create registry keys for them.

    It was a cool little application, with a slight flaw. Each time you added a user in this way, WMS would go off and check whether it could access the area, Fine if you are doing one or two accounts, but if you were doing hundreds (as I needed to do once a year), it hung the server until the job was finished, which would take up to 12 hours.

    I found this didn't happen if WMS was not running when you did the import, so I suspect the problem was hundreds of checks building up in a queue somewhere, or the service tied itself in knots . It only took a few minutes to check if the service was shut down and restarted after.

    Either way, in the next version of the app, I put in a dialog that offered to shut the service down first, and reminded the administrator to warn users first.

  8. Anonymous Coward
    Anonymous Coward

    Physical collisions are impossible

    Reminds me of an automated chemistry analysis system with a robotic archiving freezer. Every shelf spot had a corresponding sample rack with a barcode and, upon scanning the barcode, the robot arm would pull it into the -80°C freezer for later retrieval (either by rack or sample number). The low temperatures did what low temperatures do to plastics and, over time, the racks became brittle and cracked. Replacement racks were sent out and everything was gravy.

    Unfortunately, one evening, a green technician couldn't remember how to use the system to retrieve the racks assigned to his team. Instead, he discovered the old racks in the storeroom and used one of these. The robot arm tried to file it and ended up wedging the old rack into the back of the new one because there was no code to check if the shelf had previously been filled or a sensor in each spot to detect the same. The loss of two racks of samples would have been annoying; instead, the robot arm managed to domino the majority of the samples off their shelves into the bottom of the freezer, smashing up the tubes and destroying a lot of work.

    Fingers were pointed at everyone, by everyone. Eventually, the technician got saddled with the blame because the freezer manufacturer supplied a note with the new racks, warning that duplicate numbers should not be used in the system. All the remaining old racks were disposed of and, I believe, the software was updated (not that anyone dared to test it out).

    1. MrBanana Silver badge

      Re: Physical collisions are impossible

      I would like to think that the technician was not held up as a scapegoat. Early career mistake, and hopefully everyone learned. The Toy Story 2 deletion https://thenextweb.com/news/how-pixars-toy-story-2-was-deleted-twice-once-by-technology-and-again-for-its-own-good was obviously a huge screw up by someone, but they didn't judge, and moved on. Not sure all tech companies would be so enlightened nowadays.

  9. Boris the Cockroach Silver badge
    Facepalm

    More robotic mayhem

    Or never assume your fellow programmers are as good as you are.

    We had a machine with an add on robot.

    The robot had its own control program with move commands, gripper open/shut and a wait command that paused the program waiting for the machine to send a signal to execute the next bit of robot code

    The machine had 2 commands.... signal the robot to start and........ signal the robot to start and wait for the robot to send finished...

    Needless to say I programmed the robot to pick up blanks from the tray and put them in the machine according to the master plan worked out previously as the machine had control of the splash guards and clamping.

    My colleague<snarls and glares over the screen> did the machine program, so we both load up the code ready for the first test run.

    and hit the big green button.

    The sequence was supposed to go

    Splash guard open

    Robot arm in place to grab part

    Clamp release

    Arm up /wrist 180 to load blank/arm down

    Clamp

    Arm ungrab blank and retract

    Splash guard close

    The actual sequence was splash guard open, unclamp,clamp , splash guard close, arm straight through perspex splash screen, 1st tool comes down and crashes into arm before someone manages to hit the big red stop button.

    Post mortum(attentive readers will have already worked out what happened)

    My colleague<glares over the screen again> wrote his code and decided to use the 'robot start' command instead of the 'robot start and wait for the robot to finish' command

    Needless to say the machine ran through its set of commands before my robot had even got as far as deciding to try putting the part in........... then it tried to put the part in.

    Solution(H2SO4..... if only it was that easy....and I could get away with it........) I wrote ALL the robotic handling code from then on

    1. Anonymous Coward
      Anonymous Coward

      Re: More robotic mayhem

      "Solution(H2SO4..... if only it was that easy....and I could get away with it........)"

      Johnny was a chemist, but now he is no more,

      for what he thought was H2O was H2SO4!

  10. Anonymous Coward
    Anonymous Coward

    "Why we should check for bad input end errors?"

    In a project I worked on time ago, part of the system was written by our company, part from an external one. The external one complained our code was not working, because a workflow always crashed when they invoked our code. We debugged it, and found they were sending us wrong parameters, and our application returned an error code and an error message. It turned out they were not only sending the wrong parameters, they were also ignoring the errors and proceeding as if nothing wrong had happened, and of course then everything went down the sink...

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like

Biting the hand that feeds IT © 1998–2022