back to article Britain has no idea how close it came to ATMs flooding the streets with free money thanks to some crap code, 1970s style

Welcome to the start of another working week and a tale to take us back to the orange and brown hues of the 1970s courtesy of The Register's Who, Me? thread. Today's story flings us back 45 years. Skylab was still in orbit, Russia and the US were playing touchy-feely with their Apollo Soyuz Test Project, "Bohemian Rhapsody" …

  1. BebopWeBop
    Thumb Up

    Well, whoever was doing the testing earned their pay packet! I wonder how the tests were devised and how much of their content was based on 'gut feelings', beyond a few standard sets?

    1. TonyJ

      Experienced tester.

      Experience is everything here.

      I did a recent project and the customer was insistent that UAT should be prescriptively scripted.

      It took more than a few wasted hours in meetings to get them to finally see that doing that makes users do the tests in front of them and only the tests. They won't deviate and nor will they report any aberrant behaviour that isn't part of the scripted tests.

      These are people we've picked who have years of experience using the software daily. Let them do their jobs as they normally would and report the issues they come up with.

      Other tests along the way can be more formalised.

      1. A Non e-mouse Silver badge

        Re: Experienced tester.

        Users have a habit of using software in ways the designers never thought of.

        1. Caver_Dave Silver badge

          Re: Experienced tester.

          Many years ago I had the absolute pleasure of working with two testers Cheryl and Caroline. Outside of the office they were great company and we all (developers and testers) got on like a house on fire. Inside the office they had PMT ratcheted up about 1000%, which was absolutely brilliant for the job!

          The bug report I found the most amusing/terrifying went along the lines of :

          System - some employee pay and benefits system

          Problem - cannot enter minus one for number of children of employee

          Rational - Employee has divorced and their partner now has sole custody

          1. JimboSmith Silver badge

            Re: Experienced tester.

            Years ago I was given some new shiny software to test as an "average user". This was for my company and not the software firm who it seemed were very keen we liked it. I was asked to note the good and bad points whether the new UI was any good etc. So off I went doing what I considered to be a thorough run through of the thing. When I was finished I emailed a copy through to the bloke who'd asked me to do it. I was then invited to a meeting where a Rep from the software firm was ready to rebuff my 'Cons'. He hadn't been sent a copy and was coming into this ready to defend but oblivious to my criticisms. He was unhappy with quite a lot of what I'd said and tried to claw back some ground. He said somethings weren't able to be edited on purpose because if you needed to alter them you were supposed to create a new record. I said there should be a 'duplicate record' feature in that case to save having to retype sometimes lengthy info. Well we were the only people who'd mentioned that so it clearly wasn't a major thing.

            Then we got onto focus stealing I said you couldn't use the computer for anything else whilst running a report. The software was constantly swapping from one internal process to another whilst doing a report. Each time it did that, it stole focus and for example the email you were writing was stopped. Also it was very easy to hit a key whilst typing at that point and stop the report. The software firm weren't aware of that being a problem because it was obvious when their prog reappeared on screen it had focus. I pointed out I had two screens so not obvious to me. Amongst the other highlight was the GUI which had little animations for things like saving a record, which showed a card being put into a file cabinet. This slowed down the saving as it didn't save until the animation had finished.

            Also they used a unique global identifier for each record which meant it was exclusive to us. I pointed out that this would either tie us to their ecosystem forever or make migration very painful. Individual records were stored with a filename of a random series of characters and numerals. We had no control over that and it made me wary because we currently used a method of labelling records that identified the division and category in the filename.

            He gave up trying to defend after I laughed at his second use of "Our North American customers find that a valuable feature!" Suffice to say we didn't replace our existing software with their system in the end.

        2. Sgt_Oddball

          Re: Experienced tester.

          Fellow developers can get even more creative...

          1. MiguelC Silver badge

            Re: Experienced tester.

            As much as they might try, developers are never as creative at fucking systems as end-users. And end-users don't need to try to get creative, they just fuck systems up and don't even know how or why

            1. Anonymous Coward
              Anonymous Coward

              Re: Experienced tester.

              I still have no idea how I managed to get my "secure" work laptop that supposedly had all internet access (except RDP) disabled to have full internet access and I'm a firewall engineer

              1. Mike_G

                Re: Experienced tester.

                The perks of being a FW engineer (I am aswell) :) Punching an any rule for you Laptop.

              2. Daveytay

                Re: Experienced tester.

                You could touch it and Petter Nordahl-Hagen's hack still works? Pretty sure only bitlocker stops this now.

            2. swm

              Re: Experienced tester.

              My 4-year old granddaughter can find key combinations that I wouldn't believe existed. Maybe 4-year olds should be hired as testers.

              When Algol-68 came out and several people were writing compilers someone wrote a program that generated a string of Algol-68 reserved words, special characters, identifiers etc. in a totally random order. These "garbage" programs crashed a lot of compilers.

            3. HelpfulJohn Bronze badge

              Re: Experienced tester.

              "...And end-users don't need to try to get creative, they just fuck systems up and don't even know how or why"

              Oh. So you've met my sister?

        3. IHateWearingATie

          Re: Experienced tester.

          "Users have a habit of using software in ways the designers never thought of."

          Yeah, the bastards.

          Bloody users, fouling up my elegant software with their 'requirements' and 'needs'.

          1. Anonymous Coward

            Re: Experienced tester.

            Bloody users, fouling up my elegant software with their 'requirements' and 'needs'.

            If the software was hard to write, then it is only fair that it should be hard to use.

            1. Zippy´s Sausage Factory

              Re: Experienced tester.

              /me cackles in InterCAL...

          2. low_resolution_foxxes

            Re: Experienced tester.

            I seem to have a good knack for knackering beta software.

            Apparently our old software dev manager hated me for my lengthy takedown test reports. Detailing why all the wording and UI is terrible, typing names like "Sir %qwert££ - +66" and finding you can crash the app by hitting CTRL-ALT-DEL while running 5 instances from my remote laptop on a public hotel WiFi.

        4. Anonymous Coward
          Anonymous Coward

          Re: Experienced tester.

          Developers vs Users

        5. dinsdale54

          Re: Experienced tester.

          At one of my former customers, one of the operations folk was referred to as 'The Chaos Monkey' for his ability to break any code the dev team wrote no matter how much testing they had done themselves.

          He was always given the new code before anybody else. If it survived him, it was production ready.

        6. fidodogbreath

          Re: Experienced tester.

          Users have a habit of using software in ways the designers never thought of.

          Most devs test their code against how they know it's supposed to work. They then tell the test engineer how it's supposed to work; s/he tests that and also runs a regression suite against it.

          I'm a tech writer working mostly on end-user docs. I treat every product as a black box and document the behavior I see in response to stimuli. If something is clickable, I click it; if it's not (supposed to be) clickable, I click it. If a field expects integers, I try to enter decimals / text / emoji / SQL / paste in a GIF / etc. If there are start date and end date fields, I enter a start date that's after the end date. If the intended action runs a long javascript that produces an output file, I hit Reload in the middle of it. Because some rando out there will do any or all those things (and more that I can't imagine); but when they do, the product should handle it or fail gracefully.

          Let's just say I report a lot of bugs...

          1. G.Y.

            Re: Experienced tester.

            a while back:

            Me: I gave the student compiler "ali baba +40 thieves" to compile -- and smoke came out!

            Older guy: Hell -- I give my compilers .OBJ files to eat, and they better not crap out!

          2. Stork Silver badge

            Re: Experienced tester.

            It was very interesting working at Maersk Data. Some of the old hands knew Maersk Line's business better than Maersk Line did (having made shipping systems for 20+ years), and if we still had questions we knew where to ask.

            And I had one colleague; when I had disagreement with her code it always came down to interpretation of the spec. She did not do errors as such.

            1. Alan Brown Silver badge

              Re: Experienced tester.

              " it always came down to interpretation of the spec."

              THAT is a field all by itself, leading to the realisation that in English you can say "I cleaned the floor with a mop" or "I cleaned the floor with Bill" - a native english speaker knows what you mean, but someone reading things literally might take pity on Bill.

          3. UncleDavid

            Re: Experienced tester.

            I once had a car where you had to press one button to increase the time on the clock, or the other button to decrease it. Of course the first thing I did was press both at once. The clock switched to 24 hour display.

            Had a calculator that did date arithmetic. One of the first things I tried was the square root of my birthday. I eventually figured out the three numbers resulting were my biorhythms (remember them?)

            Sometimes you aren't seeing a bug but an undocumented feature or Easter egg.

      2. Phil O'Sophical Silver badge

        Re: Experienced tester.

        They won't deviate and nor will they report any aberrant behaviour that isn't part of the scripted tests.

        Yep, it only tests that it does what it is supposed to. Testing that it does not do what it isn't supposed to is far more useful (and far more difficult).

        1. John Hawkins

          Re: Experienced tester.

          Yeah back in the day when I moonlighted as a tester when work had nothing else for me to do, the fun part was going outside the prescribed the test cases and getting things to fail.

        2. Remy Redert

          Re: Experienced tester.

          Have I got a great example of that one. The social security managing software that the company I work for makes has some very interesting 'features'. For example, the client in a dossier and his partner are stored in 2 separate fields in said dossier.

          When we make a new dossier, we check the existing ones to see if there are any incompatible dossiers around and still active. If there are, we show an error. This check of course only checked for clients, not partners.

          So you could give client A and partner B their social security check and then give client B and partner A their social security check as well, paying them twice because partner B didn't already have a dossier as far as the system was concerned.

          It only took a year to get it accepted as a bug and fixed, because of course the user and their processes wouldn't allow that situation to happen in reality.

      3. trolleybus

        Re: Experienced tester.

        I visited a Unisys plant once that was close to releasing a new version of software to configure a communications controller. There were signs all round the plant asking employees to spend a given day trying to break the software in any way they could.

        I stll think a formal script is necessary, but maybe it isn't sufficient.

        1. Anonymous Coward
          Anonymous Coward

          Re: Experienced tester.

          Hardware, but similar.

          Coca-Cola used to deploy its new vending machines in company offices in order to test them before putting them into public locatations. They would then offer a bounty and have their employees try to see if they could get free products and document what they did to bypass the mechanism. One day, after introducing a new machine, they came in Monday morning to a note taped to the front of the machine that said (its been 40+ years since i was told this one) "I don't expect payment'. When they removed the note, they found that someone had used a cutting torch to remove the lock mechanism from the unit.

          1. swm

            Re: Experienced tester.

            We had a coke machine at college built like a safe. One day I watched someone violently kick the machine repeatedly near the coin slot. The machine started disgorging change and cokes with each kick.

            I discovered I could reach in the delivery chute and grab cokes that were being cooled before being inserted into the dispensing mechanism. One day I discovered a 6-pack of beer which I removed with all of the cardboard. The same day there was a fierce argument between two of the janitors.

            There was one of the first dollar bill changing machines installed in the student union. Clearly they wanted college students to test it. I took a dollar bill and taped one edge and tied a string to that edge and inserted it. There was a tremendous tug-of-war between me and the machine resulting in $1 in change and a shredded dollar bill. I arranged the pieces in the input slot and sent the pieces in. I got another $1 in change.

            1. AlbertH

              Re: Experienced tester.

              We used to modify the BT indoor payphones - the wallphone and coin-box type. A simple bit of wiring, and the party-line button marked "press" on the wallphone became useful: Make your call, and when the insert coin "pips" began, just hold in the "press" button and dial the number of 10p coins you wanted it to register!


        2. donk1

          Re: Experienced tester.

          A formal script should be automated.

          Manual testing is to add test cases which are not in the automated testing.

          If more software had telemetry (what do you mean boo!) then converting manual testing into automated tests would be easier.

        3. UncleDavid

          Re: Experienced tester.

          At Microsoft, a regular bug bash day was part of the culture. Prizes for the most bugs (subject to triage). I bet we weren't alone.

          Now the tester discipline is abolished, and devs test their own stuff (with all the perceptual and prejudicial flaws called out here) I suspect the bashes are less fruitful.

      4. John Robson Silver badge

        Re: Experienced tester.

        "I did a recent project and the customer was insistent that UAT should be prescriptively scripted."

        That's what automated tests are for, and it's valuable... You want to make sure that regressions don't occur, but that's only one string of a test, the more creative testing is far more valuable.

        But the output of the "creative" testers will inform automated tests for future versions, but the creative ways to break a system are always the most interesting - and the ones that no sane person would prescribe in a test. They're the things that an experienced tester will go ... Something odd about how that window loaded in, what if I just... <bang>

        1. Alan Brown Silver badge

          Re: Experienced tester.

          "You want to make sure that regressions don't occur, but that's only one string of a test, the more creative testing is far more valuable."

          ONLY if the developers actually take note of the reports.

          I can think of plenty of software where I've been filing the same bug reports for years and they can't understand what the issue is, because they simply don't have enough imagination to see why it's a problem.

          1. John Robson Silver badge

            Re: Experienced tester.

            You could argue then that the report isn't sufficiently detailed.

            It has to be written for the audience (in your case developers with no imagination).

            Explain why it's a problem - use the catb article for reference.

            - What system are you using

            - What did you do

            - What did you expect to see

            - What did you see

            - What affect does that have on use (what can/can't you do as a result, what breaks)


          2. the hatter

            Re: Experienced tester.

            Doctor, doctor, it hurts when I do this. Well then stop doing that.

            1. John Robson Silver badge

              Re: Experienced tester.

              It hurts when I poke my shoulder, or my chest, or my nose, or my leg.

              You’ve broken your finger....

          3. Anonymous Coward
            Anonymous Coward

            Re: Experienced tester.

            "because they simply don't have enough imagination to see why it's a problem."

            The website for the HSA-management company selected by my employer automatically logs out the user if it detects more than one page open under that user's login. That includes opening a second tab in the same browser, going to the same website. They couldn't understand why it was a problem to do this, even when I told them I had opened the second tab to get to their "help" page...

            Of course, I was opening the help page to ask why I had to log into the site TWICE each time, as the first login (after username, password, and SMS 2FA) would immediately auto-logout. They dismissed it as they "couldn't find it in the logs". I suspect the issue is that I tend to close the page instead of logging out, so the autologout timer only triggers when I log in a week later.

            Definitely a subOPTUMimal site.

          4. UncleDavid

            Re: Experienced tester.

            Or they have good intentions, but it's declared a corner case, and never gets to the top of the priority list, and the dev is getting yelled at for not moving on to the next feature.

      5. Captain Scarlet

        Re: Experienced tester.

        I always find a bit of both works best, as you will get some users query why do I need to do such and such process this way.

        Often best to get the underlings to do the testing in said departments and ensure different people repeat the tests.

      6. Doctor Syntax Silver badge

        Re: Experienced tester.

        "I did a recent project and the customer was insistent that UAT should be prescriptively scripted."

        Obviously somebody who'd never been told that no battle plan survives first contact with the enemy.

        1. baud

          Re: Experienced tester.

          'Obviously somebody who'd never been told that no battle plan survives first contact with the enemy.'

          Or at least he's never seen one of his plan die a fiery death at the hands of the users

      7. Admiral Grace Hopper

        Re: Experienced tester.

        We used to treasure our colleague Gordon who was born to be a UAT specialist. Our software would pass unit testing and integration testing, then we'd give it to Gordon. It was only a matter of time before he'd wander round to our desk.

        "If I select this, then this and press this, is does that. Is that right".

        "Why would you even try to do that?".

        "Because the software lets me".

        A perfectly reasonable response. He always found things to do that none of us could imagine. I loved him and I loved his work. Once Gordon couldn't break it, it was ready for the great unwashed.

        1. I am the liquor

          Re: Experienced tester.

          A rare talent. Sadly testing isn't seen as a very prestigious role, so it's hard to attract people with the requisite persistence and imagination to do it well.

          1. Doctor Syntax Silver badge

            Re: Experienced tester.

            Users, however, do it all the time.

        2. red floyd

          Re: Experienced tester.

          Had a buddy like that once. He broke a shell script by pasting Unicode into its inputs. I really learned to sanitize input there.

        3. TeeCee Gold badge

          Re: Experienced tester.

          Ours was called Gerald.

          He went through terminals like they grew on trees too. Ruddy things would just give up and die once he'd been at them for a while. Decent analyst, great programmer and fucking excellent at breaking things.

        4. Simon Reed

          Re: Experienced tester.

          I'm one of them buggers. And proud of it.

          As a Senior Programmer my mantra was: "If I can't break it, you can ship it, and I'll buy you a beer."

          It is very rare I can't find a way to break software. I bought them beers anyway.

          1. A.P. Veening Silver badge

            Re: Experienced tester.

            I bought them beers anyway.

            So they could cry in them?

    2. Muscleguy

      The tester is described as being an engineer and probably was. Therefore someone methodical and used to the logic of testing things such as what if x fails? what if y fails? etc.

      My father was an engineer. My attempts at self designed Meccano models had a harsh, but constructive critic.

      He worked for NZ Rail and part of his job was testing and certifiying machinery such as cranes. He had overalls for when he needed to clamber over things. He said that was something he enjoyed. He ws the sort of guy who would need to eyeball and knock every pneumatic joint, assess clearances, look for cracks etc. How might this thing fail?

      In NZ whenever there's an earthquake nothing runs while people on little motorised tractors trundle over the lines checking nothing has fallen in the tunnels, the bridge connections are intact (some of the bridges are designed to break the line if the quake is big enough so the bridge can sway independently). i expect these days they also use drones.

      1. big_D Silver badge

        Testing to destruction as well. That's what many engineers do, when they don't like something. Turn the voltage up to 11 and see what happens.

        Sticking with rail, but skipping across the water, one company I worked at helped with the Australian VFT (Very Fast Train - very pragmatic naming in Australia, I always joked it would be replaced by the FFT, I'll leave you to work that out!). A colleague was at the launch press conference and allegedly, someone from the press asked what they would do if their was a kangaroo on the track (we are talking about a train doing in excess of 120mph).

        The managers and consultants all looked at each other, shrugs were given, then some bright spark said "turn on the wipers?" I guess they hadn't thought about every scenario for the press conference, although I'm sure the engineers had tested up to camel/buffalo...

        1. the Jim bloke

          When I was a youth, they introduced the XPT express passenger trains, relatively high speed trains on rural lines. From memory, they were wiping out cars at level crossings every month or 2.

          1. CliveS

            The XPT was derived from British Rail's HST, with downrated engines, uprated suspension and a reduced top speed. As I recall, there was only 1 XPT crash at a level crossing, the notorious crossing on the Olympic Highway at Gerogery in NSW. In the run up to he XPT crash there had been numerous other crashes at the crossing, which ws eventually replaced with an overbridge called "Five Mates Crossing" after the five lads in the car who died as a result of the XPT collision.

            1. Dave559

              And, in turn, the British Rail HST (InterCity 125) was only supposed to be a relatively short-lived interim solution, pending the development of the electric APT (Advanced Passenger Train) and further electrification of the rail network.

              First introduced in 1976, they are only just now being retired from many of the routes they operated on, and in fact ScotRail have also acquired some (by now, very second hand, but still with a bit of life in them) IC125 train sets to replace rather more vanilla DMUs on their express routes.

              I'm a bigger fan of the electric InterCity 225s (which, in theory, at least, could also operate faster, and had potential for tilt capability), but the HST is definitely a design and engineering classic, and a well deserved tip of the hat to everyone who was involved with them.

              1. JimboSmith Silver badge

                First introduced in 1976, they are only just now being retired from many of the routes they operated on, and in fact ScotRail have also acquired some (by now, very second hand, but still with a bit of life in them) IC125 train sets to replace rather more vanilla DMUs on their express routes.

                I had to travel on the GWR line out of Paddington towards the end of last year. I'd done the same jouney before on an HST and as somebody else was paying had gone First. It was a very civilised way to travel with comfortable leather seats, curtains, softish lighting and a buffet to buy some hot food on the way back. Not to mention a lounge at Paddington to get away from the likes of me standing looking at the departures board.

                So when offered the chance to do it again by the same people I didn't need asking twice. The trains are shiny fast and new but that's about all the good things you can say about them. The comfortable leather seats have gone and been replaced by seats that have a horrible material and a distinct lack of padding. The lighting wouldn't be out of place in an interrogation room and from enquiries with staff cannot be dimmed. The power sockets have been moved between the seats and mean unplugging at the socket if the person in the window seat wants to get up. No curtains anymore just a blind that for some inexplicable reason doesn't cover the entire window or block out enough light. It also subjectively seemed a bumpier ride although that may be down to the granite like seats and louder. The sound absorption however minor from the curtains has gone. As has the buffet so I had to wait till I arrived before getting anything hot to eat and a proper coffee that wasn't made from freeze dried. I made sure I ate before the journey back

                I have a friend who is a train buff and he says the blame lies with the department of transport who specified the trains. They went for the cheapest stuff on the inside hence the seats. They wanted more seats hence no buffet but there is a kitchen at one end of the train.

                1. paulf

                  There is another story I heard about the IEP that was a consequence of design by Government committee. Existing HST coaches are 23 metres long. Some smart arse at the DfT design committee noted that bogies (that assembly under the coaches that encompass suspension and wheel sets/axles etc) are the most costly thing to maintain on the coach. If we lengthen the coaches of the IEP to 26 metres we get fewer bogies per seat and reduce maintenance costs. Neat huh?!

                  Cue Network Rail having to spend millions adjusting platforms across the network as the longer coaches were now foul of platform edges that were on any kind of curve.

          2. HelpfulJohn Bronze badge

            "From memory, they were wiping out cars at level crossings every month or 2."

            And this is why I would prefer overhead monorails. How they are powered is irrelevant but no part of the moving train should ever be lower than the top surface of a double-decker bus or tall lorry. That way, the advert with the little blonde girl on the level crossing would never need to be made.

            Of course, we have far too much invested in dual ails on the floor to ever consider swapping over. Even UKland's new High Speed Train is grounded and lethal.

            It didn't have to be.

            1. Anonymous Coward
              Anonymous Coward

              Re: Monorails

              If only it were somehow possible to build bridges so that roads and paths could pass under or over railway lines…

        2. Chloe Cresswell Silver badge

          I take it the one after a FFT would just be called "Strewth"?

        3. Doctor Syntax Silver badge

          "what they would do if their was a kangaroo on the track"

          Correct reply - nothing, it's the kangaroo that has the problem.

          1. Korev Silver badge

            I hope that was a joke...

            1. Korev Silver badge

              That was supposed to be hop

              1. Doctor Syntax Silver badge

                Autocorrect's a hitch.

        4. Robert Carnegie Silver badge

          "All of us, or at least all those of my generation, heard in our youth an anecdote about George Stephenson, the discoverer of the Locomotive Steam-Engine. It was said that some miserable rustic raised the objection that it would be very awkward if a cow strayed on the railway line, whereupon the inventor replied, 'It would be very awkward for the cow.'" (G. K. Chesterton)

          America's noble "Iron Horse", in one's imagination, goes about sporting a sort of shovel at the front called a "Cow Catcher" or bewilderingly "pilot". It is more of a Cow Thrower anyway. Catching is, as you cay, the cow's difficulty, not the train's.

          1. AndrewD375

            "the cow's difficulty, not the train's"

            You'd think so, wouldn't you?

            But there was in fact a fairly notable accident on the Edinburgh/Glasgow line back in the 80's, in which a cow on the line caused a complete derailment of more than one passenger coach and several people died. So it's not always just the cow's problem.

            See here:

            1. Anonymous Coward
              Anonymous Coward

              Indeed. Had that discussion many years ago with an American train driver (lots of cows where he worked). He said hitting a cow was a pretty big deal.

        5. Allan George Dyer

          @big_D "I always joked it would be replaced by the FFT, I'll leave you to work that out!"

          Slow, but intensely pleasurable?

          1. Doctor Syntax Silver badge

            Fast Fourier Transform.

        6. HelpfulJohn Bronze badge

          "... Very Fast Train - very pragmatic naming in Australia, I always joked it would be replaced by the FFT, I'll leave you to work that out!). ..."

          Well, in UKland, where every iteration is uglier, more expensive, more cheaply made, includes less seasoning in the packet, less noodles and fewer, smaller, less tasty biscuits all made with more artificial everythings, and is definitely always going to be slower, I would guess it stands for "Fairly Fast Train".

          The iteration after that would be something like SST for "Slightly Slower Train".

    3. Pascal Monett Silver badge

      Re: "whoever was doing the testing"

      Whoever it was, he was never employed at Boeing, apparently.

      But honestly, this is not a tale of a major blunder saved in extremis. This is just a normal development cycle. Developer codes, tester tests, results come back and the cycle starts again until the code is approved for production.

      That is exactly what happened.

    4. Slow Joe Crow

      When I worked in a system validation group we had on e tech nicknamed "the human corner case" for his magical ability to break stuff. My wife carries on that tradition, even with tech as simple as a car's HVAC controls.

      Also regarding expected inputs, a friend followed family tradition of giving all male children the same first name and using their middle names. This created havoc at the doctor's office since the medical records software made the staff think it was duplicate records.

  2. AndrueC Silver badge

    Many years ago I was a data recovery engineer. I was also responsible for writing and maintaining our data recovery tools. Every now and again the hardware engineers would whine about the time it was taking to image hard drives. Sometimes I'd offer sympathy and agree to investigate. It was a way to avoid real work since I could usually blame the network or the (NetWare) servers. Other times I'd just shrug it off and do something more important.

    Anyway this one time the engineers were adamant things had suddenly taken a turn for the worse. So there was a department-wide investigation. The network was checked and found to be fine. The servers seemed okay as well. Eventually we gave up and forgot about it for a week or two. Then while I was investigating another problem I happened across the main I/O loop for our disk imager. And there I found a debug statement, left in while investigating our 'non-BIOS' disk reading. This was code that used ATA to talk directly to the disk. We needed that because sometimes the BIOS just couldn't handle the state the drive was in and occasionally we took in a drive so large that the BIOS couldn't access it all. Anyway this code could be a bit temperamental and it often came down to timing.

    Hence the debug statement I'd inadvertently left in. The I/O loop read 64kiB of data then wrote it out. Then it waited 10ms before going round for more data. I toyed with the idea of pretending I'd discovered a hitherto unknown way to improve I/O but we were a friendly team so I 'fessed up. Sometimes it does you good to laugh even if it makes you look like a chump.

  3. Blofeld's Cat

    Uh ho ...

    I have never seen an engineer in a purple haze, but I have seen them turn a whiter shade of pale.

    I was part of a QA team testing an office machine that was about to be launched. We discovered it was simple to run the machine with the safety covers open. The chief engineer of the project said this was "absolutely impossible" and that we had made a mistake.

    We gathered them around the test machine and opened all the safety covers - the machine stopped and the engineer smiled.

    We left the doors open and cycled the power - the machine started and the engineer went white as a sheet.

    1. Anonymous Coward
      Anonymous Coward

      Re: Uh ho ...

      My wife was writing docs for a product, and filed a bug that it didn't work on Wednesdays. A somewhat sceptical development team agreed to humour her by looking at the problem, and found a day-of-week variable that was only 8 characters in size ...

      1. Anonymous Coward
        Anonymous Coward

        Re: Uh ho ...

        We recently shipped a product that failed after midnight. None of the testers found the bug! Fortunately most of the users are 9-5 office workers too, so very few people noticed it before we shipped a fixed version.

        Maybe that's more of a gremlin than a bug.

      2. Anonymous Coward
        Anonymous Coward

        Re: Uh ho ...

        Though a day-of-week variable should have been stored in a int or enum field, rather than a string of characters

      3. swm

        Re: Uh ho ...

        Reminds me of a bug at MIT that depended on the phase of the moon. The program would print out a program with the date and the phase of the moon. The "first quarter" had too many characters.

        We also had a bug at Xerox in the ALTO era where the IFS (a remote file server) would fail if the banner line was too long - worked in May but not in September.

      4. A.P. Veening Silver badge

        Re: Uh ho ...

        and found a day-of-week variable that was only 8 characters in size

        Probably a program that was originally written for French speaking users, the only language I know of with a maximum number of characters for the name of a day less than nine (I also checked Dutch, German, Spanish, Italian and Vietnamese).

        1. J.G.Harston Silver badge

          Re: Uh ho ...

          Reminds me of when I was called out to bug-fix an application in the early 1990s. On startup the screen would be drawn, then very quickly disappear and be replaced by a buffer overflow error. Couldn't work out what was happeneding as it happened so fast, and it worked perfectly on every other machine we tested it on.

          I ended up just running it again and again and to see if I could use persistance of vision to see where it was bombing out. It drew a line-draw window, printed a few headings, then bombed out. Hmm. So it's managing to /start/ outputting to the display. Hmmm. Can I run the code with the text output redirected to a file? Ooo, yes.

          Run application, let it bomb out, examine redirect file. It ended with:

          Disk space free: Buffer overrun

          Hmmm. Run FREE.

          Bytes free: 102,000,000 bytes (or summut).

          Chap had bought a brand spanking new shiny soopadooper huuuuge hard drive with more than 99M of free space (yes, huuuuge!) The application was trying to write a 9-digit number into a 8-digit string buffer.

          Quick fix: Save some dummy files to reduce the free space to under 100M and it worked prefectly. :)

    2. Morrie Wyatt

      Re: Uh ho ...

      This one's old enough that it's hardware rather than software testing.

      Vinten Communications used to make the radio equipment used by the Victorian Police and other emergency services.

      This was back in the days of valves and dangerously high voltages.

      They had one wiresman in particular who was absolutely meticulous in his work. Every wire of a particular colour entering one end of the loom would exit at precisely the same position with respect to all of its neighbors. This greatly simplified fault finding. (Debugging wasn't yet a part of the common vernacular.) As such, he was the go to person for all new prototypes.

      On day however, a new product was put on the test bench for it's first power on. Unbeknown to the wiresman, his colleagues had got there first.

      The prototype was duly turned on, and they watched the blood drain from the poor wiresman's face, as smoke started wafting out of the case.

      One worker was hidden away out of sight, and a string of waxed paper drinking straws had been run to an inconspicuous location on the unit under test.

      The hidden worker was blowing cigarette smoke through the straws.

      However one of the observers broke up laughing, and the ruse was revealed, much to the relief and annoyance of the poor wiresman. The device itself worked flawlessly.

  4. big_D Silver badge

    Test, test and test again...

    It was drummed into me, when I started analysis and programming, that 60% - 70% of a projects time is testing.

    You received the spec and wrote your test plan, only then did you start on the code and the test harness. You coded to the spec and test plan, you didn't write the test plan to fit the code.

    Then the code went to system testing, who only ever saw the spec, never the code, so their test plans were spec based.

    When that was complete, the test was signed off and the code put into pre-production, where the customer had their acceptance testers. Once they had signed off the code as correct, it could be moved to production...

    Nowadays, it often seems to be people throwing links between frameworks together, then throwing the whole lot "out there" and waiting for the screams.

    1. Phil O'Sophical Silver badge

      Re: Test, test and test again...

      Nowadays, it often seems to be people throwing links between frameworks together, then throwing the whole lot "out there" and waiting for the screams.

      It's called "Agile".

      1. big_D Silver badge

        Re: Test, test and test again...

        It's called "frAgile".


        1. David 132 Silver badge

          Re: Test, test and test again...

          It's called "Windows 10".

          FTF FY.

      2. Piro Silver badge

        Re: Test, test and test again...






      3. Robert Carnegie Silver badge

        Re: Test, test and test again...


      4. WonkoTheSane

        Re: Test, test and test again...


    2. AndrueC Silver badge

      Re: Test, test and test again...

      In my defence when you're writing data recovery tools for the engineers that are using them you can't always afford time for thorough testing. Most customers want their data back yesterday so you bodge up a fix for whatever is blocking that particular recovery and worry about the code later. But then there's a dual nature of the job where sometimes you had to drop the programming you were in the middle of and actually recover some data. In the early days we even had to answer the phone and give quotations to customers. Can you say 'context switch'?

      I think on balance looking back over the 15 years I did that (15 years during which the main tools were ported from DOS, to Win16 then to Win32 using both Pascal and C++) we did a damn good job.

      Happy days but history now.

    3. PerlyKing

      Re: Test, test and test again...

      This sounds lovely. I must be in the wrong industry :-(

    4. G.Y.

      Re: Test, test and test again...

      I saw an IDE (ANT?) where the tests are generated together with the code. A new project starts with a test "is 2+2==5?", which fails. The rest is left to the engineers to implement&fix

    5. hairydog

      Re: Test, test and test again...

      Sadly, that approach looks really good from a modern perspective, but it was still suboptimal.

      The test plan should be derived from the business requirements, not from the spec. Otherwise you are only testing that the system meets the spec, rather than meeting the needs the spec was meant to address.

      Nowadays, of course, people just make it up as they go along.

  5. Blofeld's Cat


    I'm old enough to remember when the tenner came in a little plastic cassette, which you were supposed to return in the slot provided.

    The street around the machine used to be covered with them.

    You also had to go into the bank branch the next day to get your "cash cards" back.

    1. John Sager

      Re: ATM

      Barclays original ATM used cheque-like paper things with a series of holes in them. They gave you a few at a time & one went back for more when they were gone One time I used one but it didn't let me have any cash. A bank employee was just leaving & asked what the problem was. He was about to give me a tenner & sort the problem on the morrow. Then he realised one of the holes wasn't quite empty, removed the offending chad & it worked perfectly.

  6. cosymart

    Acceptance Testing

    We gave our acceptance testers specific instructions. "Try and break it!"

  7. Man inna barrel

    This is why we make prototypes

    I have had a few "blue smoke moments" when testing prototypes. One of the worst was when testing a power supply for endurance at full load. It took hours for the thing to warm up, then "boomf!". I took the lid off, and there was a bit of a crater in the PCB. A few power devices had died. It looked like there had been a short, perhaps due to bad soldering. I thought this because our regular technician was busy at the time, so the production engineer did the soldering. The board was patched, and the dead parts replaced. Switch on, load up, and wait. A few hours later -- "boomf!". OK, this was not bad assembly. Something was overheating. I eventually tracked it down to a device that needed a higher voltage rating, in order to reduce leakage current that caused thermal runaway. I should have known about this, but the data that would have warned me was somewhat buried in the component datasheet. "Every day is a school-day", as my boss said at the time.

    This faffing about with repeated lengthy tests delayed the product launch somewhat, but you have to consider what may have happened otherwise. Say we shipped hundreds of PSUs in the winter, and they did not overheat at that time. Come the summer, and they start going "boomf!" all over the country. Multiple callouts at our expense, and all profits wiped out.

    1. Missing Semicolon Silver badge

      Re: This is why we make prototypes

      While "Boomf" might be appropriate, I tend to find that mains-electrical stuff goes "Spop!"

      1. Psmo

        Re: This is why we make prototypes

        Weirdest noise I got was from a soldering iron that got wet.

        Dried it out and turned it on, although it was probably dead.

        It gave a soft "ehurgh" coughing noise before committing seppuku across the table.

    2. Anonymous Coward
      Anonymous Coward

      Re: This is why we make prototypes

      "...delayed the product launch somewhat"

      Good thing, too - if it had shipped as-is, the product might have launched itself...

  8. ColinPa

    Approaches to testing

    We had one tester who had some sayings

    - There are two ways of reporting testing. 1) "We have run all of the tests, and on a good day with the wind behind us, they all passed" or 2) "No matter what we did - we could not break it". Management want 2) but will take 1) and run.

    - The point of test is to change the product until the all the tests pass.

    - Automation is great - but eventually the product is fixed and all the test run. You then change the automation - slow it down, speed it up, test different things.

    - If you haven't broken it - you havent pushed it hard enough

    My experience of catastrophe prevented, was testing on the biggest z/OS mainframes configured for High Availability, running CICS, IMS, and MQ. I ramped up the transaction rate and within minutes one mainframe had crashed. But this was configured for HA... so the work seamlessly moved to the next mainframe -for a minute, and this then crashed - and the work moved to the next mainframe - which also died.

    No one else had this problem not event the stress team - I thought it was my dodgy monitoring code.

    It turned out that under extreme load some code was not freeing "system storage" because someone had copied only 99% of a fix from somewhere else. They added the one line of code saying "this block is free" and it worked, and I could not get it to fail.

    1. A Non e-mouse Silver badge

      Re: Approaches to testing

      We had a HA system which worked fine. Then one day, the primary failed and everything jumped over to the secondary. Which promptly failed and everything failed back to the primary (which was just about getting back on its feet) Which failed, etc. , etc..

      It turned out one client got into a very weird state and sent command packets to the servers which the servers couldn't handle. Once we managed to get some logs and isolate the client the system became a lot more stable.

  9. Nick London

    The past is another counttry.

    I went to university in 1972

    I had a cash card from Natwest Bank

    It was a small plastic punch card. You put in the slot with a PIN and got £10

    They then posted it back.

    By doing this and getting the maximum on a cheque at the counter with my guarantee card,I think £25, I could pay a terms rent.

    1. Anonymous Coward
      Anonymous Coward

      Re: The past is another counttry.

      One of my friends had a card like that. We realised that it looked just like 2" cut off the end of a standard punched card, but he wouldn't let us borrow it to see if we could make a copy...

    2. MarkB

      Re: The past is another counttry.

      My reaction to the "25p a pint" was to think they were being ripped off.

      When I was at Uni, 75 - 78, a group of 5 of us used to have a regular Friday evening at the pub. Each of us paid £1 for a round - 4 of us bought rounds of beer (Hardy and Hansons Kimberley Ale) and the 5th a round of ham (or cheese and onion) baps. I think we even got 5p change each.

      1. Mike Pellatt

        Re: The past is another counttry.

        Beer (OK, Watneys Red) was around 2s 6d a pint when I started drinking in pubs in 1970 (age 15, of course). 12.5p to you.

        45 years ago was 1975. Inflation hit 25% in that year alone, 20% the year before.

        Some google research indicates 25p a pint in pubs was about right in London in 1978 (which suggests beer price rises were below inflation back then). So, I don't think he was (particularly) being ripped off.

        Of course, SU bars were much cheaper back then.

        Here, thanks to pubs being closed, our local brewery is putting a barrel outside 2 or 3 times a week, self-serve for £1 a pint in an honesty box (villagers only!!!). Happy days.

        1. jfm

          Re: The past is another counttry.

          SU bars were usually cheaper, yes—but not at Edinburgh in the '80s. The Students' Association (non-NUS-affiliated) had a policy of selling beer at pub prices and using the proceeds to subsidise cheap hot meals, so when you'd gone through your grant cheque ("What's green and takes 3 hours to drink?"), you could eat for next to nothing at the Student Centre.

          1. J.G.Harston Silver badge

            Re: The past is another counttry.

            Six pints of beer, and keep the change.

            From a fiver? Thank you very much sir!

    3. Alan J. Wylie

      Re: The past is another counttry.

      I've still got a £10 card from the late 70's / very early 80's. Photos:



      The numbers 1 to 20 on front correspond to each usage - a pin punched a small dimple. After 20 usages you got a new one.

  10. trolleybus

    Not the only Burroughs ATM story

    I worked for Burroughs/Unisys and one day an engineer told a story. He'd been called by an irate bank. I won't name them but in those days you were unlikely to find a branch south of Hadrian's Wall. One of their customers had complained that the atm had failed to issue the tenner. A long argument ensued: the engineer defended his machine, explaining that such a situation was impossible.

    Years later he was uninstalling the machine in question. Tucked away underneath he found a tenner. Rather than reopen old wounds he secreted it from the premises.

    1. Phil O'Sophical Silver badge

      Re: Not the only Burroughs ATM story

      Even the newer ones weren't perfect. Back in the late 80s a colleague was preparing for Christmas shopping, and asked an ATM for £200. It hummed & clicked, and reported that it only had £150 left, and would he take that. He selected "yes", took the cash, and fortunately kept the receipt showing the issue of £150. A few weeks later he got his bank statement, which showed a debit of the originally-requested £200.

      It took a lot of arguing with the bank ("that isn't possible, Sir"), but they did eventually agree to refund him the missing £50. We assume that somewhere a bank software engineer had to hastily create a software fix...

      1. MarkMLl

        Re: Not the only Burroughs ATM story

        There was something odd with the magstripe on those early dispensers: Burroughs used some sort of "pepperpot encoding" which I suspect relied more on obscurity than cryptographic rigour.

        The TC500 was an interesting brute. A mechanical golfball driven by steel tapes (to circumvent IBMs patent which used steel wires), and a small disc for main memory to circumvent GOK how many patents on using a drum (in particular, I suspect, the LGP-30 which was a similar serial-logic machine).

        And software was typically loaded into it using paper tape made out of recycled bog roll. Which was also used for diagnostic software, which more often than not would tear or jam with a customer breathing down your neck.

        1. Greum

          Re: Not the only Burroughs ATM story

          Ah, yes. The Secure Card Property, a few random iron filings embedded in the card. The idea was to make the card difficult to copy, but it also had the effect that it was difficult to get a consistent reading which resulted in many cards being retained because the SCP value encoded on the card didn't match. One of those failed "good ideas".

    2. big_D Silver badge

      Re: Not the only Burroughs ATM story

      I used to use Burroughs/Unisys kit and was on a training course in Milton Keynes. In the evening, we got talking and one of the Unisys instructors regaled us with a story about one of their engineers.

      He worked in some remote place and, over a couple of years, every time he visited a customer to repair something, he order 2 of the thing being replace, instead of 1. They said that nobody had noticed and he would have gotten away with it, but he tried to order a new case - no engineer hat ever ordered a new case, so they made an investigation...

    3. Danny 2

      Re: Not the only Burroughs ATM story

      I worked at Burroughs/Unisys circa '92 and I have a dozen first hand stories This is a semi second hand one.

      Somebody told me that was an entire shift that never turned up on Sundays for years, even though they were paid extra. When the shift supervisor was found out he, and his employees, were protected by their union. I'm pro-union but don't ruin that for everyone.

      The management were equally to blame, real GE type dumb wits, You had to have a swipe card to get in to corridors in the factory, and most of them were closed off to technicians and engineers. So regularly young apprentices would fry the card reader system using an electrostatic 'zapper'. Just so they could talk to the female office workers.

      It's why I think the US and UK are lagging compared to say Germany and the Netherlands. Management there is mostly consensual, or at least consultative. In the UK and the US it's more class war.

      1. heyrick Silver badge

        Re: Not the only Burroughs ATM story

        "Somebody told me that was an entire shift that never turned up on Sundays for years"

        All sorts of fraud is possible when the people that are supposed to be in charge are in on it.

        Cleaning company, large supermarket chain, circa 1992. The cleaning staff was a team of, I dunno, ten or fifteen people. They came and went. A lot. Must be nice to have a four hour cigarette break...

        Anyway, the money requested from the supermarket for the pay was for quite a number more, including employees since left/fired/got a better job, as well as a couple of dead people.

      2. Anonymous Coward
        Anonymous Coward

        Re: Not the only Burroughs ATM story

        Somebody told me that was an entire shift that never turned up on Sundays for years, even though they were paid extra. When the shift supervisor was found out he, and his employees, were protected by their union.

        A PC manufacturer in France had an automated pick&stuff assembly line running multiple shifts. Allegedly, once a week the night shift under one particular employee would change the program and run off a batch of pirate Canal+ satellite decoders that were then removed & sold. Since they were actually stealing components even the union couldn't save them when they were found out.

  11. analyzer

    lil Bobby tables

    I tried the above at the login screen for a brand new super duper system being introduced but used users instead of students, it didn't work but when I used employees it did. Anon because for some strange reason I haven't been hauled up for a disciplinary and I'm keeping it that way.

    1. big_D Silver badge

      Re: lil Bobby tables

      I did some testing for a retail outfit that was going online at the turn of the Century. It was my first security testing gig and I had to go through the site and see if it was secure.

      The first thing I noticed was no SQL Escaping... They didn't seem to think it was important, a quick demonstration of bypassing the customer logon didn't impress them, nor did listing the users table... So for my next trick... DROP DATABASE.

      Now, that got their attention!

  12. Anonymous Coward
    Anonymous Coward

    When Devs break the software!

    Posting anon, because we're still in progress.

    Working on software that executes real-time commands to a routing system. I represent end-users, the guys who sit and watch to make sure everything goes as planned. Have been asked, "What is your test plan?"

    Don't have one, because I never know what the developers are going to break in the next version! This week's update results in 900+ alarms per day due to switches not happening.* We just look at everything to see if something working yesterday is broken today.

    *Update installed on Friday. No notice, no e-mail just a flood of alarms all weekend until I logged in to check the system! What fun :/

    1. tip pc Silver badge

      Re: When Devs break the software!

      "*Update installed on Friday. No notice, no e-mail just a flood of alarms all weekend until I logged in to check the system! What fun :/"

      Thats just standard.

      I guess you work for Virgin Media

  13. Anonymous Coward
    Anonymous Coward


    We were a customers of a company that sold MPEG hardware many years ago - we would buy the PCI boards put them in PC's and sell the system.

    Had some problems where the boards wouldn't work at all - turns out they tested them on old "slower" PCs and we were using them on faster PC's.

    There was also their flagship product - several grands worth of PCI that had two notches so that it would fit in either a 3.3V or 5V slot. Except that if you put it in a 3.3V slot it will catch fire..... Their solution - put a warning sticker on it.

    There again, they used to ship "diagnostic" software, but if I had a faulty card and wanted to send it back, they would refuse to accept the output of their own test software......

  14. andy 103

    My 15 mins of shame

    Years ago I was working as a web application developer. I'd been given a legacy (read: poorly coded) application and was tasked with investigating why certain requests were taking so long to respond.

    I enabled MySQL's slow query log and had set the threshold for logging as 2 seconds. This means any query that takes longer than 2 seconds to execute gets logged to a file. The application was being used by tens of thousand of users per day. The queries were big and the log files were in the order of GB.

    I then went on holiday.

    Whilst sat on a beach I got an alert by SMS saying the server's main disk was full. That's odd, I thought, as the disk was about 250 GB.

    Not only had I made the error of leaving the query log enabled. Another developer had also written a script which was copying log files to another destination *on the same disk*. The combination of these things filled up the disk very quickly, and the application fell over.

    When I returned from my "relaxing" break I was asked why our test plan hadn't worked out. Unfortuantely tests don't always catch things, especially when they weren't reasonably foreseen circumstances at the beginning. But what makes it more interesting is when you combine the sum of those mistakes. On their own these 2 mistakes wouldn't have caused the application to fail. But when combined the result was somewhat different.

  15. My other car WAS an IAV Stryker

    My kind of testing

    When the official testers are driving the vehicle and find something odd just driving between test runs, they told us to "fix it" but it really meant "create a test to duplicate this spurious/random behavior, THEN fix it".

    More to that story here. We did manage to find a facility and test methods to consistently replicate the problem. It was mostly a mechanical issue, and some software saved the day. I don't know how many lines, but the core logic was basically three variables in, three value tests, some ANDs and ORs where "true" triggers a single output signal, in parallel with any existing logic that might trigger same signal (just another OR with existing code). The devices and wiring already existed which made it implementation relatively easy -- easier than adding hardware at that stage in development!

    And while we're talking testing, I have another relevant post here: good testing kit pays for itself; redundant copies especially.

  16. Rich 11 Silver badge

    No skin off my nose

    So that crisp £10 was not something to be sniffed at.

    Until the 80s, when coke became popular.

  17. Anonymous Coward
    Anonymous Coward

    nis table admin -fuckit

    Over 20 years back a colleague of mine managed to demote a NIS+ server with a single command meaning there was no master left or something like that.

    Neither we on the project nor Sun support could find any way back - so we rebuilt around 20 sun machines from scratch over the next 24 hours...

    Our customer rephrased whatever the actual command was to that in the title - seemed appropriate then and I still remember it now!

  18. chuBb.

    Card Eater

    When i worked in the vending industry my first project was writing the control stack for a card dispensing machine, so visitors could buy a RFID card, open an account and load credit onto card, but it could also refund excess credit by eating the returned card, and top up employees access cards. Everything went swimmingly with the dev hardware, but started to get calls as soon as the first production units were out in the wild, that cards were being issued once and eaten. Cue mass panic and fingers pointed at myself, one line by line code review later and demonstration with dev hardware that everything was in spec and we are scratching our heads...

    Finally a production unit is returned to base and low and behold it does exactly what the customer described just ate cards instead of dispensing them, and even worse would also eat employee cards who were trying to top up there card to purchase in the canteen and from vending machines, so we pulled it to peices and finally found the problem we had the inverted output version of the rfid readers installed, this was where i discovered the sort of asshats i was working for, now the TD (teflon director, the most technical he ever got was measuring his parking space and distance between other vehicles) insisted that he and he alone was responsible for all parts orders as no one else could be trusted to get it right, so of course it was my fault, because i should query the card reader determine which model was put into the machine (even though the spec had been sealed and signed off before i started would only ever use this specific model of RFID reader) and handle accordingly, at least the bean to cup coffee machines we all had on our desks as dev kit was a literal perk of the job :)

  19. N2

    8 hole paper tape all proper software should be

    Pint as it brought back fond memories

    1. A.P. Veening Silver badge

      Re: 8 hole paper tape

      Wrong, it should be 9 hole paper tape for the check bit.

      1. Rich 11 Silver badge

        Re: 8 hole paper tape

        Check bit or spindle?

        I can't honestly remember what paper tape looked like in detail now. The last program I recorded to tape ended up as Xmas decoration six months later.

        1. A.P. Veening Silver badge

          Re: 8 hole paper tape

          The last program I recorded to tape ended up as Xmas decoration six months later.

          And that probably was magnetic tape.

  20. Will Godfrey Silver badge

    Trust the user for good tests

    In the early 80s I wrote a pinball game for the BBC B. Unlike those on the market at the time, the ball in mine followed something like a parabolic curve, and you could get real control of the speed. This worked fine for me and a bunch of friends, until a new guy joined us. After familiarising himself with the game, he complained that sometimes the ball would go 'through' the flippers. We didn't believe him at first, until he was able to do it repeatedly. It turned out he had dramatically better reaction time than any of the rest of us, and (like in a real pinball machine) timed the flick so just the tip of the flipper hit the ball to get maximum velocity. The code was slow enough, and the look-aheads far enough apart that this came between two of them. The solution was one of the very first bits of 6502 assembler I did.

    P.S. I was quite proud of making rebound speed dependent on where on the flipper it hit.

  21. Robert Carnegie Silver badge

    No one?

    NO ONE commented that the money dispenser defect was a HARDWARE problem...

    Not "Sam", not The Register, and none of the readers?

    A very mature, responsible attitude, which obviously I did not expect! :-)

    Boeing 737 MAX forgetting how to fly also was a hardware problem, and not very funny, I admit.

    1. baud

      Re: No one?

      From my reading, the Boeing 737 MAX was an hardware issue that was supposed to be covered by software but wasn't, so it's a little bit of both, no?

  22. H in The Hague

    Testing, in another industry

    The video is linked to the pic at the end of the article.

  23. martinusher Silver badge

    The question should be "Who has never made a coding mistake?"

    We don't ask this question because the answer's obvious -- nobody. I know that self-testing code and bulletproof formal logic are the dream of the bean counter but the reality is that you really need someone who's not actively involved in the development to build and operate the test environment for that product. A good tester (and I've had the misfortune to work with several) is someone who's both methodical and an utter bastard. They're the surrogate user, the one with the malicious streak, someone who takes great pleasure in destroying your creation and setting new speed records for doing so if possible.

    Its really nothing personal. They exist to keep us developers honest. Off duty they're actually normal people, colleagues you socialize with.

    1. swm

      Re: The question should be "Who has never made a coding mistake?"

      When I was teaching computer science I would write, from scratch, a 20-30 line program and compile it without errors. I then told the class that I was very good but that I have about a 50% success rate in writing short "perfect" programs. I then said, "Suppose my driving was like my coding ability - 50% of my trips resulted in no crashes?" You really have to test, test, test. Even then someone else will find bugs in your code.

      1. Simon Reed

        Re: The question should be "Who has never made a coding mistake?"

        "You really have to test, test, test. Even then someone else will find bugs in your code."

        That suggests you don't know how to test.

        Contrary to what someone who posted earlier said, there is no better tester than an experienced and well trained developer who understands the language, the hardware, the operating system, the compiler, memory management, data storage, timing issues and every other aspect of what actually happens inside the machine.

        Once upon a time this sort of thing was taught; now I meet developers who don't know binary or hex and I despair.

    2. holmegm

      Re: The question should be "Who has never made a coding mistake?"

      I was always deeply grateful for the testing b* from hell at my previous job. I think 95%+ of bugs were caught by her, not users.

      Like all worthwhile things, sometimes painful, but well worth it.

  24. Anonymous Coward
    Anonymous Coward

    In honour of a departed friend..

    In honour of a dear departed friend, I share this story which happened when we first met for a software project.

    In the days when men were men, noisy but interesting hovercrafts crossed the Channel and computers still had a "turbo" button that actually did something I wrote some code for a niche application. It was to run on a PDA known as the Psion Organiser II, and I came over to the UK to finalise the code for production and discuss packaging. I arrived at Folkestone, was driven across to where he lived (past Stonehenge :) ) on what was for me still the wrong side of the road, had dinner, coded the remainder and went to bed.

    In the morning I got up, ran into my friend at the corridor upstairs and remarked "you got up early". After his quizzical look, I explained I heard the computer beep earlier for bootup. We looked at each other while it dawned on me that it had not been him, and then we rushed downstairs.

    There was his 4 year old, bashing away at the keyboard as he had seen daddy do it.

    To this day, I have never been able to work out how the kid did it, but in those few minutes he managed to zap the partition table. Now for the fun part: we needed everything ready by Tuesday, it was Sunday and worse: this was a Tandem, with a Tandem disk pack and no floppies on site (yes, 5.25", remember those?). Tandem had its own proprietary variant of (I think) MSDOS 3.1 or something, so you HAD to have their version or things would not work.

    We managed to recover on Monday, but it taught us two valuable lessons. Have a backup and never wait with updating it, and make sure the kids can't switch on the computer.. Oh, and keep a copy of the OS handy on site, just in case..

  25. Anonymous Coward
    Anonymous Coward

    I was on a course covering some new reporting 'software' the company I worked for had purchased (I think they borged a company to get it). About 5 minutes in, click click... crash.

    I laughed. Started again, and repeated the steps and sure enough - crash. So that formed the rest of my day. How many different ways could I get this to crash (it was quite a few).

    At the end of the day, the instructor came over and asked what I had been laughing about. So I showed her the numerous 'fast exits' I had found. She wasn't happy, so I asked why.

    Turns out that when our company got their hands on the software, the bit they DIDN'T get their hands on was the source code!

    The product was quietly dropped.

    1. ricardian

      A colleague and myself signed up for a course in "C" at a technical college in Gloucestershire. The notes for the course appeared to have been written in the pub the night before and the IBM PCs were on a flaky network which served the whole campus. We quickly discovered that quitting the editor in any way other than the approved method (which involved half a dozen key strokes) would crash the server

  26. Claverhouse Silver badge

    Adrian Ashfield invented the basic idea of a card combining the key and user's identity in February 1962. This was granted UK Patent 959,713 for "Access Controller" in June 1964 and assigned to W. S. Atkins & Partners who employed Ashfield. He was paid ten shillings for this, the standard sum for all patents.

    A cash machine was put into use by Barclays Bank in its Enfield Town branch in North London, United Kingdom, on 27 June 1967. This machine was inaugurated by English comedy actor Reg Varney. This instance of the invention is credited to the engineering team led by John Shepherd-Barron of printing firm De La Rue, who was awarded an OBE in the 2005 New Year Honours


    Since the first cash machine was invented in Britain it seems astounding that they chose an American manufacturer.

  27. Medixstiff

    This reminds me of my first job in retail, one of the guys had just built a PC with Windows NT on it and said how it was so good no-one could crash it.

    So I inserted a floppy disk in the drive, formatted it and from a DOS pronpt ran a dir command whilst it was still formatting, then watched his faced when a BSOD appeared.

  28. violetwilliams

    Well, whoever was doing the testing earned their pay packet! I wonder how the tests were devised and how much of their content was based on 'gut feelings', beyond a few standard sets?

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