I had a client call me in panic after he'd run a unit test script that started by wiping and recreating the database from scratch, and he'd run it against the wrong server.

Thankfully he'd just run it against a dev environment where the loss wasn't particularly severe (the prod environment is firewalled off, so he couldn't have done the same thing against that), but from the panicked tone of his messages before it was clear what had happened, I'm sure he's come to be extra careful about database credentials going forward....

We seem to have shared clients in some point in time. ;)

> The equivalent to running your production server on debug.

I worked in a company where this was the standard, and we updated the code on the fly with eclipse to fix bugs :)

Here is a little fun story:

Last year I was on a flight en-route to an Ed-Tech convention in Philly. There was on board wifi and my phone had the wifi turned on. I go and check my emails before departure and get a debug page from tomcat. My initial reaction was panic, but then I remembered that the wifi runs separately from avionics. After all the mental pictures of the plane going down in flames due to someone leaving a server in DEBUG mode disappeared I simply closed the tab, turned the airplance mode on and went to sleep. Knowing in full that I had put my life in the hands of people who are pressured into writing code that works under impossible deadlines.

That's why I think that just like the romans poisoned themselves over time with lead in their pipes we will kill ourselves with buggy code from shitty projects.

The code I speak about runs in powerplants in several countries. Non-nuclear, though, and has nothing to do with industrial automation.

Yes, shitty code will be our demise. I bet on AI.

AI? LOL. It will be some cron job running off some defense contractor's forgotten ubuntu 7 server with the password password123.