back to article When customers try to be programmers: 'I want this CHANGED TO A ZERO ASAP'

Welcome to the first proper installment of Line Break, the weekly column in which Reg readers share truly horrifying code they've seen in the wild. We started you off last week with a pilot episode involving some close encounters of the absurd kind – and we've had fantastic responses from Vulture fans, which we'll roll out …

  1. Voyna i Mor Silver badge

    Surely the last one is obvious?

    But now I'm worried that at some point in the future something awful I once did will be pilloried here. And even though nobody knows it was me, I will be mortified.

    So let's be clear; most software foul ups are organisational foulups. Failure to test, failure to specify, failure to put proper procedures in place, expecting people to work excessive hours, responding to customers without stopping to think.

    That, array handling and loop exit conditions.

    1. Anonymous Coward
      Anonymous Coward

      Re: Surely the last one is obvious?

      "[...] expecting people to work excessive hours, [...]"

      Many of the problems I had to clear up in other people's code - were where they had stopped working at an inflexible point in their working day. What could be called 9 to 5 patterns. When they returned after the break - they didn't continue the code properly as they eased themselves back into what they had been doing.

      I tried to leave - early or late - when there was a clean break that didn't leave hanging threads in the middle of a piece of coding.

      1. banalyzer

        Re: Surely the last one is obvious?

        With you all the way on this one, work all the way to a logical stop and get off the programming bus then.

      2. breakfast

        Re: Surely the last one is obvious?

        As an alternative to this, if you need to leave at a certain time for whatever reason, leave it in a broken state so your code won't build. The error message when you start the next day will remind you where you were at.

        1. RoboticRabbit

          Re: Surely the last one is obvious?

          Leave it on your screen IF you won't get yelled at for not checking your code back in at the end of the day.

    2. Amorous Cowherder
      Facepalm

      Re: Surely the last one is obvious?

      Been there, done that and probably have the shirt somewhere, although it was usually only a frustrating 45 mins at most. Ah the follies of a youthful coder who thought he knew-it-all, only to be slammed back to earth by the genius of an inadvertent infinite loop!

      1. VinceH Silver badge

        Re: Surely the last one is obvious?

        With all the 'clever stuff' snipped out for the example, it may have been slightly less obvious; there may have been references to SUCCESS in that, but which didn't set it at all, so it becomes a wood for trees situation.

        It does bring to mind my younger days. On a YTS at college, when the class was doing some programming. The instructor was trying to help a girl with her program, but couldn't understand why, when run, it appeared to do nothing.

        I took a glance, pointed to a part and said it's an infinite loop - with a quite similar cause to the example here. The instructor told me I was wrong (IIRC, I was told I couldn't possibly spot such a problem so quickly) so I stepped in, added something at a key point to display the contents of the test variable on screen, and ran the program again. Unsurprisingly, the screen just scrolled the same number on each new line.

        I then got told off for "breaking" the girl's program.

        1. heyrick Silver badge

          I then got told off for "breaking" the girl's program.

          Ah, the joys of a teacher who doesn't want to be shown up. Far too many of them in the world...

          1. This post has been deleted by its author

          2. VinceH Silver badge

            Re: I then got told off for "breaking" the girl's program.

            "Ah, the joys of a teacher who doesn't want to be shown up. Far too many of them in the world..."

            Yeah, but things did change. I can't remember how far into the year that was - but as it progressed, the guy did come to realise what I was capable of. Somewhere down the line I stopped being a student and started assisting, and at one point while the class was learning some rubbish or other he tasked me with writing a nice little database for his model cars.

    3. Anonymous Coward
      Anonymous Coward

      Re: Surely the last one is obvious?

      Well it is obvious NOW. In my defense there was a lot of other things going on in the code. But definitely a slap in the head moment after. And no, no issues with hours or anything to justify it.

      Thankfully I don't recall if I wrote it or just spent the time trying to fix it.

    4. Lallabalalla

      Re: Surely the last one is obvious?

      Yes. And I probably did that myself once upon a time.

      In my experience most software bugs or errors are the result of cut-n-paste

      1. Simon Harris Silver badge

        Re: Surely the last one is obvious?

        I wonder if for that one, at some point during development getStatus() wasn't behaving correctly, so someone thought during debugging "for now, let's keep the loop going even if the status is wrong" and forgot to correct the conditional later.

  2. Anonymous Coward
    Anonymous Coward

    SUCCESS

    Well, even if that one can't be spotted, any decent analysis tool would report what's up within nanoseconds.

    However, it is a common problem, especially in organizations that do hardware (including mechanical) and software that they will spend £LOTS on physical tooling, but £ZERO on software tools.

    1. Anonymous Coward
      Anonymous Coward

      Re: SUCCESS

      > any decent analysis tool would report what's up within nanoseconds

      ... or the compiler, if using a stronger typed language. Letting ints be booleans is just rope to hang yourself with.

      1. Lysenko

        Hahahaha...

        Don't get me wrong, I'm with you. A properly typed language (like Pascal) wouldn't allow SUCCESS to be assignable (because it would be a const) and wouldn't allow an int as a Boolean (without explicit typecasting).

        However, if you think this sort of minor sloppiness (characteristic of curly bracket languages) is bad then never (NEVER) even think about looking at the crazed lunacy the PHP type hallucinator can come up with.

      2. Roland6 Silver badge

        Re: SUCCESS

        Letting ints be booleans is just rope to hang yourself with.

        That's one of the joys of C, it gives you plenty of rope...

      3. oldcoder

        Re: SUCCESS

        That woudn't change anything - it would still be acceptable as SUCCESS would then be a boolean.

        1. Lysenko

          SUCCESS would then be a boolean.

          What would change is the code would visually scan as:

          while True do

          begin....

          ...which is obviously suspiciously infinite. When you check the block and find no break, goto or exception you have the bug. No possibility of SUCCESS changing value in a pass by reference function.

  3. RIBrsiq
    Pint

    "I'm ashamed to say this took a good week and two engineers to work out,"

    Eh...? Actual programmers were they? Or civil engineers or what have you?

    Anyway, thanks for making me feel good about spotting the issue as soon as I read the relevant code even almost... 15 years, I think it's been...? God $deity! But time flies!!... since I last actually wrote any code.

    1. Paul Crawford Silver badge

      Volatile?

      That example was (presumably) an easy one, no change to tested variable/condition.

      What does catch folk out is when "SUCCESS" is supposed to be changed in some asynchronously called function (interrupt, or signal), maybe in another file, in which case the bug is usually not declaring it as 'volatile' and the compiler optimises the test to an endless loop, instead of checking the memory location "just in case"

      1. This post has been deleted by its author

      2. Number6

        Re: Volatile?

        What does catch folk out is when "SUCCESS" is supposed to be changed in some asynchronously called function (interrupt, or signal), maybe in another file, in which case the bug is usually not declaring it as 'volatile' and the compiler optimises the test to an endless loop, instead of checking the memory location "just in case"

        Been there, done that, a few times. I've also done the simple version as above - usually as a quick hack to fix/check something else and then kicked myself a few minutes later when I actually read the code. Sometimes one has to really screw up to hammer home the point, at which stage the embarrassment (even if only internal) stops it happening again.

      3. Paul Cooper

        Re: Volatile?

        I can recall ancient fortran compilers that would "optimize" pseocode like this to a loop that was either executed once or forever:

        while (rand(j) < 0.5) {

        Do stuff

        }

        Because j never changed in the loop, it assumed that rand(j) never changed and optimized rand(j) outside the loop! And of course, half the time the loop would execute once, and the rest of the time it would never exit.

      4. tomalak

        Re: Volatile?

        And then you have a new bug, because volatile does not erect a memory fence so your data access is unsynchronised. What you should really be doing is surrounding both the get and the set with MUTEXES ... and then volatile has no further effect anyway because the mutex prohibits the optimisation you were trying to avoid. Conclusion: volatile is irrelevant for multi-threading. (It still has value when you're reading from a memory location populated by some low-level piece of hardware ... say it's mapped from a PIO or something ...)

    2. theModge

      I'm choosing to suspect that the clever stuff was sufficiently distracting that they failed to spot the blindingly obvious....

      1. TRT Silver badge

        I must admit... I just spent a real two minutes rereading that code thinking, "Nah, that's too bleeding' obvious. Must be something deeper."

        1. Dave 126 Silver badge

          Akin to real life, when looking for car keys. If they are on the desk right in front of me, I don't spot them.

          1. TRT Silver badge

            when looking for car keys...

            I have an invisible serving spoon. Every single frigging time, crock of hot roast potatoes slowly heating up my hand through the oven glove and I'm stood looking at a milk jug stuffed with utensils, entirely unable to see the very shiny metal serving spoon that's right in front of me. And it's not just me... my flatmate's the same. We can both spend ages searching through this forest of utensils looking for the spoon that is right there in front of us.

            1. Queasy Rider

              Re: when looking for car keys...

              Same problem here. Had to paint a frequently used tool blaze orange because I could never spot it in my toolbox.

            2. Roland6 Silver badge

              Re: when looking for car keys...

              We can both spend ages searching through this forest of utensils looking for the spoon that is right there in front of us.

              What I 'love' are those instances where you drop something important, can't see it for looking, give up and put your eye's/hand on the dropped item straight-away, as if you knew where it was all along...

            3. Michael Thibault

              Re: when looking for car keys...

              >... spend ages searching through this forest of utensils looking for the spoon that is right there in front of us.

              "There is no spoon."

              Didn't you get the memo?

          2. Flocke Kroes Silver badge

            @Dave 126

            "Akin to real life, when looking for car keys. If they are on the desk right in front of me, I don't spot them."

            Hold some imaginary car keys, insert into an imaginary lock and twist. The real car keys will magically appear. This trick will work for any distinctive tool that you have recently seen without noticing.

        2. akeane

          IRONICALLY enough...

          Using UPPER_CASE for a variable name makes it read like a #define which you would expect to be a constant anyway (yes, I know that upper case for a #define is a convention, but one pretty much adhered too) which immediately draws one's attention that the while() conditional probably isn't changing...

          I.e. doing something weird alerts the hapless engineer to the issue for the wrong reason...

          That's assuming the code is C though...

          Two weeks though? I spotted it in under a micro fortnight!

          1. jhop

            Re: IRONICALLY enough...

            It was c++. No idea if it was actually uppercase, it was a long time ago. May not have actually been success, might have been running or! Stopped. But the principal is the same.

        3. Anonymous Coward
          Anonymous Coward

          >"Must be something deeper."

          To your credit, I'm sure. By contrast, I read it through once (assuming that what was present was the minimum sufficient for illustration's sake) and got the 'stuckness' in that pass. I don't program.

    3. Roland6 Silver badge
      Pint

      "I'm ashamed to say this took a good week and two engineerscontractors to work out,"

      Now I understand...

      Pint, because suspect much of those two weeks consisted of prolonged roundtable discussions of the form that are best held offsite...

  4. WonkoTheSane
    Holmes

    What are the odds?

    In the first example, what are the odds that the ex-programmer who called in was the one who wrote that comment in the first place, back when the world was young?

    1. gv

      Re: What are the odds?

      I shudder to think what the rest of that codebase was like.

      1. Lallabalalla

        Re: I shudder to think what the rest of that codebase was like.

        I think I know the guy that wrote it

    2. Anonymous Coward
      Anonymous Coward

      Re: What are the odds?

      One thing that bugs be about that comment is that it doesn't explain (even vaguely) why making the change would be so disastrous ... there is not even a "I don't know why but in all my testing shows that ..." remark. And it's not like the comment was some really terse one-liner, which might well lack such detail (eg simply "DO NOT CHANGE THIS EVER!!!")

      Perhaps it really /was/ deliberate booby trap ... but then why the warning?

      It all seems rather odd to me.

      1. TRT Silver badge

        Re: What are the odds?

        Oh, and he said one more thing. He said, "Someday a kid or an old guy with crazy hair is gunna come asking questions about it. And if they do... kill them."

      2. LDS Silver badge

        Re: What are the odds?

        Right. Also there's a "glitch" that leads to think that value should be changed. Why the "glitch" wasn't removed the proper way in the first place? If it couldn't be removed but with major changes, it should have been documented there or somewhere else (with a reference in the code), i.e. in defect tracking system - and still customers may not like software exhibiting "glitches", thereby it has to be fixed eventually.

        It looks a case of "it works this way, never touch it, because we don't know exactly why it does, but if you change it, it's worse". Not the way I like to develop software.

        1. DJV Silver badge

          Re: What are the odds?

          It's a bit like a big red button with the sign "Do not press, EVER!"

        2. Jack of Shadows Silver badge

          Re: What are the odds?

          Back in the day, I'd stumble across glitches in the OS, compilers, libraries and such. I'd lay a detailed explanation in what's wrong, what my fix does, and when the vendors were notified so when a new version came along, the maintainer could just search and the bug fixes in the codebase would pop-up. I knew that I definitely wouldn't be around forever so it was just the courteous thing to do.

          All new bugs were theirs.

      3. allthecoolshortnamesweretaken Silver badge

        Re: What are the odds?

        "Perhaps it really /was/ deliberate booby trap ... but then why the warning?"

        Get a label printer.

        Print out labels saying "Please don NOT press this button".

        Stick labels next to any kind ob button.

        Wait for it...

        1. Peter Simpson 1
          Facepalm

          Re: What are the odds?

          CSB:

          I have a Bosch refrigerator. It's very nice. However, it does have one feature which I have never before seen on a refrigerator: an on/off button. We installed the refrig, and were surprised to see that the light didn't come on when we opened it. Read the manual, found the button (at the top, near the hinge, marked with the circle-with-a-short-line power symbol), pushed it, and all was well.

          Fast forward now, to the day we came back after a long weekend. Cleaners had been in and one of them had thought it a good idea to press the power button, thereby turning off the refrigerator. They do a good job cleaning, but frequently do something random like this. Luckily, it had only been off for 24 hours and things had not thawed.

          There is now a prominent label next to the power switch: "DO NOT PRESS THIS BUTTON".

          1. Yag

            Re: What are the odds?

            Would be better to cover the switch.

            1. Peter Simpson 1
              Thumb Up

              Re: What are the odds?

              Good idea.

              The Germans (or Chinese) had thought of that. The button, which is located on, and sits proud of, the mating surface, fits into a carefully crafted recess in the door itself, meaning that the cover would need to fit into the space between the button and the recess, in order for the door to close.

              I haven't crafted the custom cover yet :-)

              I'm puzzled that someone even thought an on-off switch was necessary on a refrigerator. At least, they put it high enough so that inquisitive little fingers couldn't reach it.

            2. Wensleydale Cheese Silver badge

              Re: What are the odds?

              "Would be better to cover the switch."

              Shop floor version: Use Araldite,

          2. jeremyjh

            Re: What are the odds?

            Bosch seem to love this. I have a toaster with a power switch that isn't the thing that lowers the toast into it. This seems mainly to be so that +/- switches and flashing lights can be used for things that really just want a slider.

          3. heyrick Silver badge

            Re: What are the odds?

            Umm... if you had to press a button to turn the fridge on, what happens after a power cut?

            1. TRT Silver badge

              Re: What happens after a power cut?

              A power restoration?

            2. Roland6 Silver badge

              Re: What are the odds?

              if you had to press a button to turn the fridge on, what happens after a power cut?

              My freezers have a power on button, if power is off for more than a few hours and/or the internal temperature rises to a critical threshold (ie. the door has been left open), it will either power off totally or won't power back on. It's a feature to do with food safety and preventing the refreezing of unfrozen food.

            3. Peter Simpson 1
              Thumb Up

              Re: What are the odds?

              ...what happens after a power cut?

              The switch is bistable, so it retains its state through power failures. At least they got *that* right...

      4. John Sanders
        Holmes

        Re: What are the odds?

        Sounds like a made up history to me.

  5. OzBob

    Hmm, is the last example an endless loop

    because it never passes the value of "status" to "SUCCESS"? or never tests if status == SUCCESS?

    We had a brilliant one at my old company in the UK, an officious manager who said in a meeting "I should know, I used to be a DBA" and the head DBA (very technically capable) said "Yes but you weren't a very good one".

    1. A Known Coward

      Re: Hmm, is the last example an endless loop

      The latter. SUCCESS is a constant and shouldn't be changed, hence the CAPS (all caps for constants is a widely followed convention).

      1. Anonymous Coward
        Anonymous Coward

        Re: Hmm, is the last example an endless loop

        While variable names and styling give an indication of what the variable is and does, you can't (and shouldn't) rely upon this. If you want the variable to be a constant, define it as such.

        const int SUCCESS = 1;

        You say it is a widely followed convention, but it isn't one I have seen in the organisations I have programmed with.

    2. Anonymous Coward
      Anonymous Coward

      Re: Hmm, is the last example an endless loop

      <<We had a brilliant one at my old company in the UK, an officious manager who said in a meeting "I should know, I used to be a DBA" and the head DBA (very technically capable) said "Yes but you weren't a very good one".>>

      Bit like this ---> https://www.youtube.com/watch?v=x-a5B6xM5s4 (takes a while but you'll see what I mean)

  6. Josco

    Any chance of a solution?

    Not all of us here are programmers and I could stare at that code for an eternity and not know what I'm looking for.

    I do a little HTML, CSS and PHP and some aeons ago a small amount of classic ASP, all of it laughably simple. I've always thought of coding as a little like Shakespeare; I can read Shakespeare, I can understand (some) Shakespeare but I certainly can't write it.

    1. disgustedoftunbridgewells Silver badge

      Re: Any chance of a solution?

      it should say:

      while(status == SUCCESS) {

      Currently it's just doing a while(1) ( as SUCCESS is set to 1 )

      1. frank ly Silver badge

        Re: Any chance of a solution?

        "while(status == SUCCESS)"

        That's assuming that getStatus() returns a 1 or not_1 as appropriate. Often, it's assumptions all the way down, especially if other people have been writing/modifying other parts of the system.

      2. Annihilator

        Re: Any chance of a solution?

        "it should say: while(status == SUCCESS) {"

        I was half expecting it to be a case of "while(status = SUCCESS)", the classic schoolboy C-style error of assigning a variable, not testing. Why I was always taught to have "constant == variable" as the test, so that any missing = would throw an error.

      3. nigeb

        Re: Any chance of a solution?

        Just to be pedantic :) you should probably get into the habit of reversing the test ie.

        while (SUCCESS == status)

        Assuming you actually remembered to make SUCCESS a const, or a #define, this stops you causing another disaster by accidentally omitting one of the = signs - you'd be stuck in the loop again.

        1. disgustedoftunbridgewells Silver badge

          Re: Any chance of a solution?

          If you did

          while ( SUCCESS = status );

          Then it would work as expected, because ( ( SUCCESS=status) == status ) .

          It also wouldn't change the behaviour, even for future uses of SUCCESS, because it wouldn't exit the while loop until SUCCESS was set back to 1.

    2. Adam 1 Silver badge

      Re: Any chance of a solution?

      Nothing sets the SUCCESS variable back to 0 so the while loop is infinite.

      Hopefully getstatus method isn't too resource intensive...

      1. Warm Braw Silver badge

        Re: Any chance of a solution?

        Actually, I've seen similar cases where the loop would exit, though unpredictably, owing to the equivalent of getstatus corrupting the stack (or failing to preserve registers). Those ones really do warp your mind.

        Though any decent compiler in the example quoted should have optimised out the test and issued a warning...

        1. Anonymous Coward
          Anonymous Coward

          Re: Any chance of a solution?

          "Actually, I've seen similar cases where the loop would exit, though unpredictably, [...]"

          The fictional scenario of passengers waiting for the lemon-soaked tissues unusually overlooked the unreliability of any cyclic state continuing forever. There is always an "unknown unknown" - or even just a "very unlikely known" - that will cause it to end prematurely.

      2. TheOtherHobbes

        Re: Any chance of a solution?

        >Nothing sets the SUCCESS variable back to 0 so the while loop is infinite.

        You mean someone forgot that nothing succeeds like SUCCESS?

        1. nicboyde

          Re: Any chance of a solution?

          Nothing succeeds - like a budgie with no teeth.

          That's what we were taught, anyway. Possibly I didn't go to very good schools.

    3. QuiteEvilGraham

      Re: Any chance of a solution?

      Given that it uses an ancient COBOL idiom, it really is kinda like Shakespeare (COBOL originally only had do something until ... loops, where the test is made at the bottom before looping back). Applying that idiom in 'C' or similar is a fine cause of malarkey when you use it with do something while ... loops, where the test is at the top of the loop. Full marks for 1TB though.

      Keep at it though - simple things usually only appear that way because you've kept your wits about you.

      1. Anonymous Coward
        Anonymous Coward

        Re: Any chance of a solution?

        "[...] where the test is at the top of the loop. "

        IIRC Pascal always executed a FOR loop once - even if the condition suggested the limit had already been reached. One of the Pascal "Common 10 mistakes" when moving to it from another language.

        Always felt that "C" could have done with := rather than = for assignment. That would have prevented the = and == mistakes in C.

        1. Anonymous Coward
          Anonymous Coward

          That would have prevented the = and == mistakes in C

          It wouldn't have prevented it (as the grammar would still allow an assignment within a conditional), but it may have helped to make it easier to spot.

    4. Robert Carnegie Silver badge

      Re: Any chance of a solution?

      I think if you aren't a programmer then this may not be the series for you. Although the web server that executes any UNIX command in the URL (in it is in fact doing that) doesn't require a programming qualification to appreciate. So efficient! :-)

      I can imagine encoding an "rm" cleanup command in the parameter which would invoke the equivalent actual "rm" command on the server, without recognising any other UNIX command input.

      But even then it might be unwise.

      1. Ken Hagan Gold badge

        Re: Any chance of a solution?

        "Although the web server that executes any UNIX command in the URL [...] doesn't require a programming qualification to appreciate."

        In fact, anyone who reads El Reg thoroughly will (at least this week) appreciate that a remote attacker could even wipe the UEFI firmware on your server this way.

        The stories are all good. Perhaps they are too good. I know truth is stranger than fiction, but that also means that sometimes it is harder to believe.

    5. Borg.King
      Coat

      Re: Any chance of a solution?

      Add the following to the bottom of the loop:

      if (!SUCCESS) {

      break;

      }

  7. Anonymous Coward
    Anonymous Coward

    Maybe the customer wanted SUCCESS changed to 0 ?

    ( And, seriously, a week and two engineers ?! ).

    1. disgustedoftunbridgewells Silver badge

      Rubber ducking would have solved that in 30 seconds.

      1. getHandle

        You obviously use your rubber duck very differently to me...

        1. disgustedoftunbridgewells Silver badge

          I can't tell if you're joking, but if you're not, rubber ducking is describing the code, line by line, to a rubber duck. You reveal the bug in explaining it.

          1. TRT Silver badge

            Ah!... So that's why my boss keeps an inflatable Mandy doll in his stationary cupboard.

            1. Doctor Syntax Silver badge

              "So that's why my boss keeps an inflatable Mandy doll in his stationary cupboard."

              What does he keep in his mobile cupboard?

              1. TRT Silver badge

                What does he keep in his mobile cupboard?

                Duh... his mobile of course.

                *red faced as bad autocorrect of fat fingered typing of stationsry cupboard isn't spotted*

          2. Flocke Kroes Silver badge

            Re: Tell it to the duck

            Do you have expiremental evidence that a duck is more effective than a more traditional SITSE partner?

    2. Andrew Moore Silver badge

      I'm going with two "engineers"

  8. Anonymous Coward
    Anonymous Coward

    Three glasses of whisky

    The last one looks obvious - but it is a case of the brain seeing what it expects to happen - rather than what the instructions actually will do. Lay people have difficulty in understanding that you can't lie to a computer - being too precise can also be wrong if there is an unknown factor.

    In the old days it was the sort of problem that you knew you just couldn't see for looking - it had to be obvious.

    As a very occasional drinker I would look at such a problem while working through three glasses of whisky. The increasing intoxication meant my thinking became slower and slower - and eventually I had to reason very hard about each step in the code.

    Usually I spotted it by the third glass - otherwise I went to sleep. If I was lucky the answer rose unbidden as I awoke the next day.

    That only works if a small amount of alcohol has that effect on you - regular drinkers would have a higher threshold.

    1. TRT Silver badge

      Re: Three glasses of whisky

      I find tea has a far quicker effect. If by the third mug you haven't solved it, you simply set a condition "I cannot leave my desk until this is solved." The problem then quickly shifts to one's secondary (some might say primary) processing centre located around the pelvic region.

      If you piss yourself, you can declare the problem insoluble.

      1. Anonymous Coward
        Anonymous Coward

        Re: Three glasses of whisky

        "I cannot leave my desk until this is solved."

        Sometimes it is the act of leaving your desk that gets the mind off its tramlines and the answer becomes clear. Many times in my career I have given up on a problem and left the office. Then 100 metres down the road had to turn back as the answer had just occurred to me.

        Managers often put the coffee machines in working areas so the staff don't spend too much time away from their desks. In fact it is the break of a moderate walk that is often most productive.

        1. TRT Silver badge

          Re: Three glasses of whisky

          This is true. An AFK break does do wonders for clarity of thought. That's why I keep my spare pair of trousers in the downstairs locker room.

        2. Dave 126 Silver badge

          Re: Three glasses of whisky

          > In fact it is the break of a moderate walk that is often most productive.

          Of a book of error codes. "It says [error] -41 is: "Sit by a lake.""

          https://xkcd.com/1024/

        3. BenR

          Re: Three glasses of whisky

          "Many times in my career I have given up on a problem and left the office. Then 100 metres down the road had to turn back as the answer had just occurred to me."

          This happens to me ALL THE TIME - although normally when I'm about 200 metres from home rather than 100 metres from the office.

          It is intensely annoying, as I then have to try to *remember* the solution for the next day!

          1. Omgwtfbbqtime Silver badge
            Trollface

            Re: Three glasses of whisky

            Email your reasoning to yourself. Then you can pick it up in the morning.

            Or have 3 glasses of whisky and email it to your boss and HR for added amusement.

        4. Voyna i Mor Silver badge

          Re: Three glasses of whisky

          "Then 100 metres down the road had to turn back as the answer had just occurred to me."

          I used to wake up in the middle of the night with the answer to a lot of problems. On more than one occasion I realised that I had been barking completely up the wrong tree and a different approach was needed. That's why I don't believe in "stay till its fixed". It just puts pressure on to come up with a fix without unravelling too much code that should not have been written like that.

          I guess it depends on your mindset. One partner at my father's firm used to deal with case papers, instantly forget each one when he was up to date, and then start the next case. He would get through his caseload, go home and play bridge. My father, on the other hand, might have several things going at once but left the office promptly at 5:30. During the evening he might have a eureka moment, scribble a note to himself and deal with it next day. They both seemed to do about as well as one another.

        5. Doctor Syntax Silver badge

          Re: Three glasses of whisky

          "Many times in my career I have given up on a problem and left the office. Then 100 metres down the road had to turn back as the answer had just occurred to me."

          I think the explanation is that we have a fairly full mental model of whatever it is we're working on but what's on the screen focuses us on a tiny part of it. Leaving the screen removes that focus but the model only decays slowly so that the brain is able to keep working on it unconsciously for some time.

          I found the solution might pop up as I walked across the car park. Or just having joined the motorway - concentrating on driving must have been particularly effective at removing the last elements of the screen focus.

  9. Owain 1

    a week and 2 engineers

    The bug is fairly obvious. I suspect though that the circumstances of the actual execution, and the knock on effects (software gets stuck in a loop) may have been non-obvious. The OP doesn't say whether this whole thing was conditional... i.e. maybe the whole code isn't triggered very often. Or maybe it's triggered by a non-obvious scenario. Imagine this was in the controls of a custard factory machine, and it is part of the nozzle blockage handling routine... Maybe the nozzles don't get blocked very often. Maybe they do but the whole factory gets coated with custard and so diagnosis of what went wrong is 'sticky'. However what it does point to is a lack of automated testing of the software. Which should have found this particular issue quickly... solving it shouldn't take 2 engineers though.

    Maybe the engineers were being charged out by the hour ;)

    Maybe the first one couldn't work after injuring himself through laughing.

    1. Nigel 11

      Re: a week and 2 engineers

      Do we now have an explanation of the bag with 59 sachets of salt and one crisp?

      (I've twice found a solid chocolate Kit-kat. I don't regard that as any cause for complaint).

      1. wyatt

        Re: a week and 2 engineers

        I have also experienced a solid chocolate kit -kat, very tasty it was too!

        1. Anonymous Coward
          Anonymous Coward

          Re: a week and 2 engineers

          And why does the coffee from the supposedly fuzzy logic "can compensate for any water condition, temperature, air pressure, mood of user" AI coffee machine taste almost, but not quite, entirely unlike coffee and more like shitty mud?

          Probably bad java.

          1. Anonymous Coward
            Anonymous Coward

            Re: a week and 2 engineers

            Don't choose the 'Fijian Kava' flavour then.

      2. Anonymous Coward
        Anonymous Coward

        Re: a week and 2 engineers

        "Do we now have an explanation of the bag with 59 sachets of salt and one crisp?"

        Happened to me when the salt was in little blue twists of paper. There were also reported cases of 1 baked bean in a can of tomato sauce.

        Google found this in several newspapers recently

        http://www.express.co.uk/news/uk/639922/Student-lifetime-Kit-Kats-legal-threat-wafer-less-chocolate-Nestl

        1. TRT Silver badge

          Re: Baked beans solitaire problem.

          That was a fault with the sauce code.

        2. Anonymous Coward
          Anonymous Coward

          Re: a week and 2 engineers

          I don't know about 1 bean in a tin, but I came close when I ordered steak and chips in a posh hotel restaurant and was served a steak and exactly two chips. One less and it would have been steak and chip. Can't blame software for that one.

          1. TRT Silver badge

            Re: served a steak and exactly two chips

            "And how did Sir find Sir's steak, Sir?"

            "Oh, I just moved a couple of peas and, what do you know, it was there all along..."

        3. Thomas 6

          Re: a week and 2 engineers

          The comments on the Express story are atrocious.

          1. Anonymous Coward
            Anonymous Coward

            Re: a week and 2 engineers

            "The comments on the Express story are atrocious."

            Yes, I would agree. You always expect one or two ignorant idiots but every comment was full of racial slurs.

      3. CraPo

        Re: a week and 2 engineers

        http://www.legalcheek.com/2016/02/kings-college-law-student-uses-1930s-case-law-to-demand-lifetime-supply-of-chocolate-after-getting-eight-kitkats-with-no-wafer/

      4. IsJustabloke Silver badge

        Re: a week and 2 engineers

        I had a solid kitkat once a day for a week ! It's all been downhill from there :(

    2. AdamAdam

      Re: a week and 2 engineers

      Well, first of, they were facing hundreds/thousands lines of code and did not know how many errors they were looking for.

      We've been shown several lines of code with the pointer that there's an error here. It's easy to be smug.

    3. Anonymous Coward
      Anonymous Coward

      Re: a week and 2 engineers

      This is pseudo code as I remember it from many years ago. The function was many pages long in practice, with lots going on. And part of a system where other components were passing the success to it. Multi Threaded and all.

      and yes we felt very sill afterwards. We have all been there.

      Sure I wasn't going to send an example of good code was I!

  10. Nigel 11

    Customer always right?

    Surely in the first example there was a moral obligation to all other stakeholders in the company. An edited version of the comment (minus the "idiots" "fools" "morons" ad-hominem bits) should have been made available. "The full code contains this cautionary comment ... please confirm, in writing, that you nevertheless require the change which is so strongly cautioned against to be made".

    Maybe the moron would have had second thoughts. And maybe you should even have tipped off his CFO, though you'd probably have needed to go up to board level of your own company to get that approved, and doing it without approval would take a lot of balls.

    1. Doctor Syntax Silver badge

      Re: Customer always right?

      Why edit it? Just quote it in full.

      1. Nigel 11
        Flame

        Re: Customer always right?

        Why edit it? Just quote it in full.

        That might have had him looking for a scapegoat, and you might have been it. In general, do not try to put out a fire with petrol.

    2. paulf Silver badge
      Alert

      Re: Customer always right?

      "So I show the code comment to my boss. He shrugs his shoulders and says:

      "Well, go do it – it's what the customer wants..."

      Nick tells us the company in question, true to the source code comment's warning, is no longer in business. Lesson: Customer is always right."

      The customer was being a major asshat KnowItAll and wanted it changed and wouldn't accept no or reasoned argument for an answer. In the circumstances Nick did the right thing checking with his boss - I just hope this was one part of some major in triplicate arse covering before Nick made and delivered the change as demanded by the customer. The customer got exactly what they wanted.

      It would be interesting to know how much this change contributed to said company's failure and whether it did so according to the prophesy of the comment.

    3. Anonymous Coward
      Anonymous Coward

      Re: Customer always right?

      No, the customer is not always right

      But the customer is always the customer and sometimes, no amount of counseling will save them from themselves

    4. Anonymous Coward
      Anonymous Coward

      Re: Customer always right?

      How did he know it was line 345?

      If he had the source code he would see the comment himself, if he didn't have the source code he wouldn't know the line number (assuming it is production code) and there's no way he would be able to remember a line number...

      1. Will Godfrey Silver badge
        Unhappy

        Re: Customer always right?

        At one place I worked, when asked for source code they always stripped out everything that isn't essential for compilation (except copyright and licence headers). they also 'simplified' variable names.

        I didn't stay there long!

      2. Mark 85 Silver badge

        Re: Customer always right?

        I was wondering that also... <absurd mode on> so maybe he wrote the code, hated the place he was working... and shorted the stock in his possession. Company slides to the bottom of the pile, he makes a fortune on the stock, and gets revenge. <absurd mode off>

        Absurd maybe... but there is the question about how did he know the line...? And the motivation for changing it?

  11. Anonymous Coward
    Anonymous Coward

    Many years ago as a junior support programmer I was supposed to help experienced applications people with intractable problems in their programs. This meant someone would put a listing on my desk and say "the machine's faulty" - showing me the failing section of code.

    I would often be looking at a programming notation I had never used or being trained in. So I would progress through the code saying in all honesty "and what does that do?" - and they would explain it to me. It was amazing how many times the person would soon say "Why of course - that's the answer - you are clever!".

    Throughout my long career it was a good technique for helping people to solve their own problems.

    1. Doctor Syntax Silver badge

      "Throughout my long career it was a good technique for helping people to solve their own problems."

      And, of course, for solving your own. I found that out ... Good Lord! Was it really so long ago?

    2. TRT Silver badge

      And it still works to this day. But beware the class of manager who, even if it was YOU that pointed out the obvious error, thinks "I saw that, what am I paying them for?"

    3. Anonymous Cowardess

      http://www.rubberduckdebugging.com/

    4. Andraž 'ruskie' Levstik

      I do this as a sysadmin - when trying to help our devs sort out issue and figure out if it's a systems or a devs prob - I'd sit down with them and they would show me stuff and then we would go through stuff more or less line by line.

      It's one of the more fun aspects of my work to be honest. As frustrating as it can be at times it's fun.

      Guess it helps that most of my learning of coding was through pseudo code(some actual coding as well but the good stuff was the pseudo code stuff) and actually tracing through that required pen and paper to solve at times.

    5. Roland6 Silver badge

      Throughout my long career it was a good technique for helping people to solve their own problems.

      And throughout my career, it is a good technique to teach junior programmers to write good code with comments ie. code wasn't just to be written. Plus they got exposure to many programming styles, some good some terrible and hopefully they adopted some of the better practises.

    6. waldo kitty
      Devil

      I would often be looking at a programming notation I had never used or being trained in. So I would progress through the code saying in all honesty "and what does that do?" - and they would explain it to me. It was amazing how many times the person would soon say "Why of course - that's the answer - you are clever!".

      Throughout my long career it was a good technique for helping people to solve their own problems.

      In other words, you were being a "rubber duck" ;)

      I don't know when I discovered it but it was way back some 40+ years ago that problems just stuck with me and I absolutely had to solve them. Invariably I talked to other folk not even involved about them and discovered the answer during that talk. One thing I found helpful was to convert the problem to something the other person understood (eg: auto mechanics). When spark plugs are used in place of blahblah and they ask "what if you used different spark plugs" it is amazing how quickly the light gets turned on.

      That thing about using all CAPS for constants or defines or whathaveyou? Never heard of it. I taught myself programing from books on machines that didn't have lowercase. Some of those machines I built myself. Even back then all CAPS was like being shouted at. As soon as lowercase was available, I jumped on it and tend to do everything in lowercase. Sometimes I may use CaMeLCaSe but it is rather rare. I always forget if the "l33t" way is with the consonants being upper or lower or if it is some random schmeck that someone is throwing out there.

  12. Phil O'Sophical Silver badge

    customized codebases

    we used to customize our product for individual customers, so we maintained a DAT tape of the source code specific to each customer.

    Rarely a good idea. Over time as the codebases diverge even the simplest bug fix becomes harder and harder to to apply to each custom build, and takes longer each time. Eventually you end up doing nothing but housekeeping and no new development (I've seen it happen, just before the company in question ran out of money).

    It's also risky, we once had a supplier that did this with #ifdef-type processing. When looking at a new code drop one day I saw code that was unrelated to our product. Not only that, it was clearly code for a competitor that I should not have seen. Relations with the supplier were very cordial, one phone call later produced a new code drop, and an embarrassed request to delete every copy of the old one and forget we ever saw it. Trust works both ways, so of course we did so, nothing more ever came of it.

    1. LDS Silver badge

      Re: customized codebases

      I would have kept the code into a VCS with customer branches - as long as the customization are not large enough to make each of them a separate product. It could also be helpful to identify common parts which don't need customizations (or only little ones) and move them to a separate "core" project.

      But I've seen too many project start as a custom project for customer X and its peculiar needs, then trying to sell it to Y and Z, of course trying to customize for their peculiar needs also. Soon you have a Frankenstein project - if you don't take the time to redesign it and isolate "peculiar" needs.

      1. Doctor Syntax Silver badge

        Re: customized codebases

        "But I've seen too many project start as a custom project for customer X and its peculiar needs, then trying to sell it to Y and Z, of course trying to customize for their peculiar needs also."

        I nearly got sucked into one of those. It was also a case of "If that's where you want to go I wouldn't start from here", largely in consequence of the peculiar needs of X. It was monolithic so every user had access to every function in the system. It needed a re-write just to remove the spaghetti tying the multiple functions together.

        Then the salesman persuaded Z that it would be a drop-in replacement for their existing system despite a misfit of data architectures...

        I managed to escape PDQ.

        1. DaLo
          Facepalm

          Re: customized codebases

          "Then the salesman persuaded Z that it would be a drop-in replacement for their existing system..."

          No way, can't believe it. An honest, knowledgeable salesman promising the earth to get a sale and then letting the tech team/customer sort it out afterwards. Scandalous, never happened in the history of the earth.

      2. TomPhan

        Re: UNcustomized codebases

        One place I was at for only a few months would customise their product for a new customer, then send an update to all the existing ones - regardless of whether it wiped out the customisation that had previously been done for them.

    2. Anonymous Coward
      Anonymous Coward

      Re: customized codebases

      " Eventually you end up doing nothing but housekeeping [...]"

      Known as the "spinning plates" problem. Have also heard it called "the Cream problem" after a modular product that spawned many successful customer variants.

  13. MacroRodent Silver badge

    C considered harmful

    One strand in many programming horrors is that they are in C. I know C well, have used it almost daily around 25 years, used to love it, but now believe it should be used only by specially licensed people, or not at all. The reason is NOT that it allows low-level access, buffer overruns etc, but because its syntax and semantics are chock full of completely unnecessary pitfalls (many of which have unfortunately been inherited by its successors like C++, Java and Javascript). Don't believe? Quick, what does this totally valid fragment of C print:

    typedef enum {val1, val2, val3} mytype;

    mytype var = val2;

    switch (var) {

    val1:

    puts("1"); break;

    val2:

    puts("2"); break;

    val3:

    puts("3"); break;

    }

    1. LDS Silver badge

      Re: C considered harmful

      You can write horrible code in any language of your choice. Maybe the effects will be more or less dangerous depending on where it runs, but as the example showing getting OS commands from a web page well explains, you can create havoc in many different ways.

      Any programming language should be only used by "specially licensed people" <G>. Heck, I should call a qualified electrician to change a plug, and everybody without the proper training should be allowed to write code? <G>

      1. MacroRodent Silver badge

        Re: C considered harmful

        You can write horrible code in any language of your choice.

        Sure, but some languages make it easier than others. But what I am really griping is about enabling (indeed, promoting) trivial mistakes. Forgetting "break" in C "switch" branches is one good example (and is known to have caused at least one widespread phone network outage!).. Allowing fall-through to the next branch is sometimes useful, but in most cases you don't want it. So the default action at the end of a branch should have been the opposite, and there should be some syntax to indicate the exceptional fall-through action.

        1. LDS Silver badge

          Re: C considered harmful

          Every language has its pitfalls if you don't master them enough well. It is true some older ones have designs more difficult to master, while some newer one are designed to sandbox the developer to try to avoid some mistakes (and pay him or her less...). But you can easily fire in your feet with any language. Take for example Python identation - if people don't follow code standards properly, and their editors are not set up properly, you may overlook some not correct identations that may lead to not correct execution paths.

          I have the habit of writing immediately break statements when I write the skeleton of a switch one, exactly to avoid to forget one. Also, most IDEs able to run code analysis tools will usually warn of such issues - I don't feel a diminished programmer if I don't use a pure text editor with a command line interface - coding in the 1970s meant far smaller applications and code - I do expect in the XXI century to have machines help me to write and manage more complex code spotting mistakes I could make inadvertelntly.

    2. GrumpenKraut Silver badge
      Boffin

      Re: C considered harmful

      Upvote because you made me think. For those as undercaffeinated as me: the word 'case' is missing thrice.

      But, as others already said, similar things are possible in every single language.

    3. tiggity Silver badge

      Re: C considered harmful

      FWIW, some of the stuff I have seen in perl makes C positively easy to read.

      Seen too many people use both the above languages to write essentially obfuscated code as a job security methodology - making it a total pain for anyone else to decipher & them almost indispensable.

      Whatever the language, obfuscated code is possible, code review by someone else before commit to your source code repository of choice is good practice (and obv. the reviewer should not be an obfuscation fan)

      1. Anonymous Coward
        Anonymous Coward

        Re: C considered harmful

        Two comments about languages stick in my memory.

        "If a Pascal program compiles then it will work - . a "C" program always compiles"

        "The "C" language allows you to shoot yourself in the foot - "C++" allows you to blow your leg off"

    4. Frumious Bandersnatch Silver badge

      Re: C considered harmful

      Are you complaining that someone forgot to put in 'case' or that enums start from zero?

      In the first case, there are only around 30 or so reserved keywords in C. There are only two types of conditional statement (unless you count for/while). My point is that C is a pretty tiny language and if you use it for any amount of time you just know that switch and case go together. Why does it have to be 'case X:' and not just 'X:"? Because the latter is reserved as the syntax for defining a label so that you can jump ('goto') to a point later (and, yes, you can mix cases and regular labels--look up Zed's Device as a variant of Duff's Device). C is so small that you're expected to be able to make these kinds of distinction and always have them in your head.

      In the second case, you can assign a constant value to one of the enumerated names and get var1=1, var2=2 and so on. But I don't really think you're complaining about that.

      1. Anonymous Coward
        Anonymous Coward

        Re: C considered harmful

        The "error" must be the missing "case" keywords. Counter-intuitively it is the experienced "C" programmer who would miss the error. Their brain would fill the gap with the expected keyword.

        That was the conclusion of the BBC programme on the brain and "reality". The visual system is too slow to process all the information - so it fills in details with memories of what it expects from experience. Hence the common problem of seeing what you expect to see - and not seeing what you don't expect to see. The latter being the classic "gorilla" in plain sight that the brain appears to treat as an S.E.P (Someone Else's Problem).

        A recent picture did the rounds online - find the panda in the array of snowmen.

        http://www.buzzfeed.com/javiermoreno/here-are-all-the-hidden-panda-photos-people-have-been-going#.bvORNybne

        The BBC programme also suggested that time appears to slow down in an emergency because the brain is having to pay more attention to actual visual detail - and that processing takes longer.

        1. MacroRodent Silver badge

          Re: C considered harmful

          The "error" must be the missing "case" keywords.

          Correct. I myself have made this kind of mistake years ago, and it took a very long time to find! (even started to suspect a compiler bug). Also have seen it a couple of times in code by others. The brain indeed tends to fill in the "case".

          The only indication the compiler gave was some non-fatal warnings about unused labels, which tended to get lost in the noise of other minor warnings.

          1. Down not across Silver badge

            Re: C considered harmful

            The only indication the compiler gave was some non-fatal warnings about unused labels, which tended to get lost in the noise of other minor warnings.

            Then it would best to write code so that there are no "minor warnings" :-)

  14. Alan Johnson

    The comment about the one and zero sounds apocryphal

    The comment is just too perfect and makes no explanation at all as to the mechanism or what the minor glitch is. It is also extremely unprofessional in tone. If such a serious situation can arise from such a small change is the whole design/architecture inappropriate? How do we know if some other bug may not cause a similar effect through a shared mechanism?

    As for the prediction of the demise of a client company and the transfer of blame to the victim rather than those who wrote the software, it will appeal to those of us who code for a living, it makes us feel important and superior, but I suspect that a real story is being exaggerated or just made up.

    1. TRT Silver badge

      Re: The comment about the one and zero sounds apocryphal

      I've often come across comments I left myself in my code, warning myself not to change something that I think will fix some problem, but will, in fact, have knock on effects. Usually as a result of trying that fix once before and finding out the hard way. For example, using "0" to represent a generic value or undefined case. I decided that it should, in fact, be NULL not 0, like in the other tables, but found that there were 6 other pages referencing that table that expected and required that undefined cases were represented by a 0. Or the note I left myself warning that there was a reason that the variable in this function had a special scope applied to it.

      The most frustrating f***ups of recent days have come from developing code both at home and at work. Dreamweaver is a massive piece of shit, but I kind of like it. It has this odd quirk where if you have the files view set to "Remote", so you see the files on the server, and click to open the file, it opens the locally cached copy without checking if it varies from the remote (live) version first. So you invariably end up opening an old version without that tiny change you made a few days ago in the other location and reintroducing the old bug, but you've now overwritten the working version and you have to wait to get to the other machine in order to restore it, by which time you've forgotten the fix you made which was your whole reason for opening the file in the first place.

      1. LDS Silver badge

        Re: The comment about the one and zero sounds apocryphal

        That's usually an issue when people use hardcoded valuesinstead of defining and using constants, and then ensure the proper constants are used everywhere.

        if you defined the UNDEFINED constand as some value (i..e. 0) you can change it later (i.e. 0xFFFFFFFF) without having to chase all the code where you tested for 0. This a very simple example, but I've seen to many people avoiding using constants and types like enumerations which lead to better, sounder code, and more readable also, relying instead of "known" hardcoded values.

        Sometimes I believe the refusal of some to use modern, powerful IDEs or code editors, and relying on simpler ones, lead them to write lazy code for lack of useful code navigation tools. And of course real programmers never use code analysis tools...

        1. TRT Silver badge

          Real programmers ARE code analysis tools...

          Analysis.

          From the Latin anus meaning 'ring' and Greek luein (through Latin) meaning 'loosen' or 'break apart'. Hence to tear someone a new one, esp. violently.

    2. Doctor Syntax Silver badge

      Re: The comment about the one and zero sounds apocryphal

      "The comment is just too perfect and makes no explanation at all as to the mechanism or what the minor glitch is."

      It sounds to me like the result of some PHB dictating a kludge RIGHT NOW instead of re-writing a section of code to do a proper job.

    3. GrumpenKraut Silver badge
      Devil

      Re: The comment about the one and zero sounds apocryphal

      > ...unprofessional in tone.

      We had a problem where we were supposed to add functionality to a program a part of which a certain 'X' (not his real name) was supposed to deliver. We waited in vain for X to do his part. Finally one of us added the part X was supposed to do, plus the added functionality. Comment went (translated from German):

      "This wouldn't be such a bloody mess had X, that lazy mongrel, done his job."

      X worked for the customer we made the program for.

      Program was shipped in source code. Customer shipped code to all his customers.

      Apparently not a single person looked into the code for all those years, as no report came to us.

  15. myhandler

    Surely that first item is nonsense.. what company would happily change a specific item of code at a customer's request?

    They might change what a piece of code *does*, but changing a 1 to a 0 is non compliant, certainly not ISO whatever that number is, and the manager who said "yeah ok " would get fired straightaway.

    1. Robert Carnegie Silver badge

      Here 1 perhaps is a semaphore flag that means "Test that the data meeting valid accounting standards", things like sales x tax rate = salestax and so forth. Disabled (set 0) in development when processing produced no output at all with no visible reason, necessarily enabled at all times in the live system.

      I agree that these stories probably are edited down to get us to the punch line faster.

  16. Anonymous Coward
    Anonymous Coward

    The invisible gorilla

    http://www.theinvisiblegorilla.com/

    1. Anonymous Coward
      Anonymous Coward

      Re: The invisible gorilla

      The BBC series "The Brain with David Eagleman" explores how the brain interprets our surroundings. The theory is that most of the time it is painting in the visual detail from assumptions of past experience.

      http://www.bbc.co.uk/iplayer/episode/b06y8hyr/the-brain-with-david-eagleman-1-what-is-reality

      1. TomPhan

        Re: The invisible gorilla

        But haven't we all seen that experiment so many times that we shout "There's a GORILLA!" whether we see it or not?

  17. Phil W

    I used to program there

    Is it just me that noticed the guy saying "Maybe you should employ some decent developers for once." is implying in saying that that they do not and have never employed any decent developers, immediately after saying he used to be one the developers?

    So what he effectively ends up saying is, "This is what I want, I know what I'm talking about! Actually I'm an idiot!"

  18. Boris the Cockroach Silver badge
    Happy

    I was looking

    at the last problem and thinking

    "Bet no one has set bounds checking on an array, so the loop only exits when the array gets so large it overwrites the value of success with 0 "

    1. Flocke Kroes Silver badge

      Re: I was looking

      For better obfuscation, use self modifying the code for the exit condition like Mel did.

  19. Frumious Bandersnatch Silver badge

    1st story makes no sense

    Did the guy requesting the change have multiple personality disorder or something? Personality #1 deduces that personality #2 will take over at some point and writes the comment to achieve some sort of victory over him? Did the guy wanting the change realise his mistake later and then travelled back in time to insert the comment when he was working for the original company?

    Also, since each customer has his own version of the code, how does changing it for that customer affect the company writing the code? Surely even if they use the program themselves, they don't run a customer-customised version of it in house?

  20. Spanky62

    Zero/One: The author of the comment is a lazy buffoon.

    Too harsh you say?

    The comment doesn't describe the specific consequences of a change because the author couldn't be arsed do any testing and find out. Hence lazy.

    The comment doesn't describe the underlying cause, because the author is too stupid to analyse it. Hence buffoon.

    Their fury at their own stupidity drove them to write that ridculous comment where they fling their faeces at some supposed future querier of their illusory authority.

    The firm deserved to go under, whether because they didn't have the code reviewed, or because they did review the code and nevertheless didn't school the author.

  21. DWRandolph

    Who The Hell Did That?

    My first impulse at some chunks of work is "What Were They Thinking?". Sometimes realize I was the one who wrote that, and ask "What Was I Thinking?". Often the answer is it was a workable solution, given the constraints at the time it was done. Sometimes things that worked then, do not work now after changes in scope or use; then I owe folk a beer. Even if it still works, I will shake my head and vow to never do crap like that again!

  22. This post has been deleted by its author

  23. John Tserkezis

    A thousand years ago, we were approached by a client who insisted on writing some software in MS BASIC (yep, I did say a thousand years ago), but wanted us only to debug it.

    Since I was the only one writing software at the time, I said either WE'LL write it, or nothing. I made it quite clear I wasn't going to do anyone else's debugging.

    Sure you lose a job, but that one? I think we did well in dodging that bullet.

    1. Anonymous Coward
      Anonymous Coward

      "I made it quite clear I wasn't going to do anyone else's debugging."

      Long ago I divided programmers into rough classes of "developer" and "support" people. They appeared to be dependent on people's particular intrinsic human traits.

      The "developer" person could really only debug their own code. If writing a patch for someone else's code they would produce an obvious "blister" that reflected the way they would have written the original code. It's logic and style would be that of the "developer". It often addressed the symptom and not the root cause - which sometimes caused another problem.

      A "support" person could debug both their own and other people's code. When writing a patch it was seamless and indistinguishable from the original style. Sometimes it amounted to no more than a tweak that made the original code run smoothly. When developing their own projects they would include a lot of contingency handling.

      Overall it seemed to be a case more of "nature" rather than "nurture".

      One example was code that needed to be enhanced to support two devices of the same type - instead of the original one. After a few problems it finally worked - so no one queried how it was achieved.

      Later on it needed to be extended to three devices. It was found that the "two" enhancement had been done by using a large sprinkling of branch decisions throughout the module to decide which device's control block was being addressed.

      The enhancement to three (or more) devices restored the code to its original state by removing all these added branches. It then added a line of code to load the data base register with the address of the appropriate device's control block. The original designer's code had used that base register to determine the current device.

  24. Anonymous Coward
    Anonymous Coward

    @Nick's story

    The monkey looked the buzzard right dead in the eye and said

    "Your story's so touching, but it sounds just like a lie"

  25. Anonymous Coward
    Anonymous Coward

    I have seen legacy code with things like:

    True = true

    do while True

    if (something) then

    True = false

    end if

    end while

    if (True) then

    'why doesn't this work anymore???

    end if

    and

    (some code)

    'remove this after 2012 june release

    if (1=2) then...

    only no one remembers if the thing was removed but not the comment, or even what the thing was that should have been removed, or if the if(1=2) is the removal, or if the if(1=2) is what was meant to be removed, so now both the comment and the if(1=2) block remain forever, just in case someone works out what the hell that code is meant to do, and finally removes whatever was meant to be removed.

    Also,

    'I have uncommented this line. it has been commented out for a while but I can't work out why. if anyone has a problem please let me know.

    And one more:

    call invert()

    sub invert()

    'WARNING: extid and extref have inverted meanings for the rest of this file!

    tempid = extid

    extid = extref

    extref = tempid

    end sub

    yes. the warning is in the sub.

    And even better

    call SetBackEndValue(value, 1) '<=== DO NOT COPY THIS LINE, not ever! And especially not the '1'

    I found it copied (complete with comment) in about 50 places...

  26. razorfishsl

    Te sad thing is this 'SUCESS' code might actually work...

    if it was a global variable and set in an interrupt routine.....buried in a totally unrelated section of code.

    The horrors I have seen and been party to in 40 years.....

    One of the greatest uses for this sort of programming was in the commodore 1541 disk drive

    the BVI flag, if i remember correctly could be branched on which was an overflow condition

    so

    :loop NOP

    Bvi loop

    Then a situation the 6502 processor had an extra pin to allow this flag to be set externally......normally never used, but they used it as the BYTE clock for the read /write head, since it was way faster than setting & reading a port.........

    IE 2 clock cycles as opposed to 8

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

Biting the hand that feeds IT © 1998–2019