investigating software

Do you know what a fall guy is? the answer is you. Why? Because when you're told that there is a human in the loop means... there is a you shaped person to blame. So, while you are working harder than ever, using the latest tools money can buy or tokens can build - someone has decided that you are responsible for all the downstream failures. It's as if shipping more, responding to customer feedback, product owner judgement calls, SRE reports from production at an ever increasing rate is not enough - they want you to review it all, and be confident (as the engineer/manager in the loop) that its "all good".  If it isn't good, then you will likely be the human in the noose . The Fall Guy, A classic 1980s TV show:  IMDB Any discuss a on how much we should delegate to AI tools degenerates to this well-meaning and slightly nervous statement: we should keep a human in the loop. We are trained Apes, yet we are meant to hang around waiting to be blamed. The orthodox positi...

Alan J. Portis once quipped that: "the best book on programming for the layman is Alice in Wonderland, but that's because it's the best book on anything for the layman". In the same theme, I'd like to suggest an addition to your library, the best non-technical book on AI Agents for the layman is "Frankenstein; or, The Modern Prometheus" by Mary Shelley. Why? Because it brings home the key facts about autonomous agent aspects like quality, autonomy & speed (I can see what you’re thing, i.e.: pick any two). The book, unlike the ubiquitous screen adaptations and sequels, digs deep into the motivations & feelings of responsibility on Dr Frankenstein, the Monster's creator. It’s clear Mary Shelly had an inkling of the sort of mayhem a spirited agent could get up to, and the anguish that would cause. The parallels with modern software development and AI engineering are uncanny. For example, the doctor creates his ‘agent’ after a period of intense ...

At 1524h, On the afternoon of January 15th 2009, US Airways Flight 1549 was cleared for takeoff from Runway 4 at New York's La Guardia airport. The airplane carried 150 passengers and 5 flight crew, on a flight to Charlotte Douglas, North Carolina. The Airbus A320's twin CFM56 engines had been serviced just over a month prior to the flight. The plane climbed to a height of 859m (2818 feet) before disaster struck. Passengers reported hearing several loud bangs and then flames being visible from the engines' exhaust. Shortly thereafter the 2 engines shut-down, robbing the Airbus of thrust and its primary source of electrical power. At this point the Captain took over from the First officer and between them they spent the next 3 minutes both looking for somewhere to land, while also desperately trying to restart their aircraft's engines. What Happened? A flock of birds had crossed the path of the Airbus and several had struck the plane. Both engines had ingested bi...

At a client site, a few years ago, I had an interesting discussion with a 'senior programmer'. Our discussion centred on a configurable home-page. A user could decide what news or other information etc, they wanted to display on their home page. They'd start off by being given a generic page - and the customer could add or remove certain types of content to customise their page. Once they saved the 'new look' site, their choices would be saved on the web-server. The company didn't want to force people to login, or even make them sign-up for an account. The goal was to keep it simple for the user. But they needed a way to uniquely identify the users, so they used an existing feature of the website. The first time a user came to the site, they were cookied with a 'unique' id 'code'. We could then use this identifier as a key in our database to store the details of what the users had configured their homepage to look like. The testers reading th...

Recently, I was testing a new feature for a client, it had a known bug, that I'd found in prior testing, for which we'd figured-out a work-around. I was now performing further testing of the feature, hoping to discover more issues and figure out how it behaves a little better. Does not apply to testers. By this time, the work-around had become the norm - the expected mode of operation for the feature. Essentially this 'bug' had been found and was now fixed. Time had moved on. So what did I do? I ignored the work-around, applied my 'test load' to the system and activated the new feature. The failure was somewhat spectacular. A short while later the entire system was inoperable and a restart of several servers was required. This was interesting. If I'd had expectations of what would happen, then it would of been for something simpler, less severe and closer to what had happened when I first found the bug that required the workaround. After some invest...