Welcome, brave souls, to a spine-tingling journey into the dark side of Software! ?
Today is not just any ominous Friday the 13th; it’s in October, the scariest month of the year! A sense of eerie anticipation fills the air, and the spirits of technology’s dark side emerge from the shadows to haunt us once again. And this blog is no exception; it’s time to delve into the sinister world of software horror stories!
Join us for a series of hair-raising stories that will make you think twice about clicking that “Update” button. Be prepared to confront the eerie, the bizarre, and the downright chilling as we unveil these sinister stories from the software world. It’s the ultimate tech nightmare – just in time for the spookiest time of the year!
Stay tuned and be ready to embrace the digital terror, for the darkness within the software world is far more ominous than you can imagine.?
*** Note: These stories are employees’ past experiences not during their time at Slingshot. The purpose of this collection is to have fun and laugh at past mistakes. ***
Story #1: Tech Can’t Breathe
“I have one that has stuck with me for years. Before Slingshot, I worked for a company with an enormous data center and an ORS. If you don’t know, those put out fires. To put it simply, it malfunctioned one day. The person monitoring the data center didn’t reset it after it malfunctioned, so it went off. And if you didn’t know how an ORS works, they suck all the oxygen out of the room to kill the fire.
“This disaster shut down the entire company’s critical systems. It took weeks to get everything back online and damaged hardware because it had all overheated. We all had to work overtime for several weeks to get things back up and running. I can’t image how much it all cost in the end.”
Story #2: Dead Men Tell No Tales
“At one of my old jobs, we had an affectionately named “Dead Man’s Button.” The idea was that if the alarm ever went off, somebody would run and hit the button to hold the doors open long enough for everybody to get out. The problem was that as soon as they would take their hand off that button, the door would close and an oxygen reduction system would kick in. Of course, we never had to use it, but it was always looming in the background.”
Historic Horror: Bitcoin Hack, Mt. Gox, 2011
If you remember, in the early days of Bitcoin, Mt. Gox was the largest cryptocurrency exchange. But in 2011 they had a major software snag: a glitch that created transactions that could never be redeemed, adding up to $1.5 million in lost bitcoins. To make matters worse, they got hacked a few years later and lost 850,000 individual bitcoins (valued at ~half a billion USD at the time). They tried to recover some, but it wasn’t enough, and they had to declare bankruptcy.
Story #3: I See You(r ID)
“This story comes from my first day at a new job (not Slingshot). I noticed that their application was set up so that a new window would pop up when you logged into their website with the address bar hidden. I was curious why they did that, so I started digging into the code.
“It turns out that after you logged in, they would connect to the database, check your account access information, and then put the connection string in the address bar. That’s how they pass that connection string back and forth from page to page. However, that meant every single webpage that opened had the user ID and password right there in the address bar. And all you had to do was right-click on the screen to view the address bar.”
Story #4: A One-Way Ticket
“My first job out of college was with an amusement park. We kept all our season pass holder data in this database. One day, I accidentally deleted a few 1,000-season pass holders. Thankfully, we recovered this information in time for the season pass holders to enter the park; backups are critical. Almost everyone in software has screwed up a database query at some point, and it sticks with you. I triple-check everything before making any no-going-back choices.”
Historic Horror: Y2K, 1999
In case you forgot or are a part of Gen Z, one of the most popular fear-filled software stories is the Millennium Bug, aka Y2K. In 1999, people were worried that computer systems would go haywire when the date changed to 2000 since most computers only used two digits to represent the year. That meant when the clock struck midnight on New Year’s, no one knew how computers would handle the 00 digits. People predicted all sorts of disasters, from banks collapsing to power outages to lost data.
But the ending was not a spine-chilling horror story; instead, it was very anti-climactic. Most systems made changes beforehand, so everything worked pretty smoothly. Still, people spent tons of money getting ready for the worst. The US alone was estimated to have spent $100 billion on ‘doomsday preparing’ for a storm that never came.
Story #5: Torture by Keyboard
“At my old job, we used Amazon to cache objects from the database, so we didn’t have to hit the database each time. Without letting us know, somebody had changed the model. We pushed out a release that suddenly started throwing errors. It was trying to match the model with what was on the server, and it wouldn’t work since it had been changed. We eventually figured out the problem but realized that the cache would expire by the time we could get a fix out. The best option was just to sit there and ride it out. We knew it would be an hour of errors, but there was nothing else we could do.”
Story #6: A Waking Nightmare
“Back during the beginning of the pandemic, I worked for a bank. This was around the time the paycheck protection program was getting started. That meant we had to build something that could handle these PPP loans. Every day, they would host an eight-hour-long call to ask them questions about how the program would work and how we needed to code the solution.
“The worst part was that each day, there would be changes to the program as they tried to figure out the details. That meant every day we would wake up and completely change whatever had been built the day before. We were tying it into our back-end system, and they had no sandbox environment. We were not able to fully test our code at all before going into production. The day it launched, we processed over $100 million in loans. All with our fingers crossed that it would work.
“We were working 16-hour days, and we were told that for all the extra work, we’d get a bonus vacation day when it was all over. By the way, we never got that vacation day.”
Historic Horror: Failed Launch HealthCare.gov, 2013
Back in 2013, The government attempted to launch Healthcare.gov based on the Affordable Care Act of 2010. The act stipulated that there needed to be an official healthcare exchange platform by October 1st, 2013. However, the site had major issues on launch day, including frequently crashing and lacking necessary features. It was so bad that only six 6 users could submit their health insurance applications on the first day.
Through a boatload of updates, upgrades, and team switching, the website was finally ‘useable.’ In the end, 1.2 million users could sign up before the enrollment period ended. Thanks to the excessive post-launch rework, the rollout of the healthcare.gov website ballooned from the initial $93.7M budget to an eye-watering cost of $1.7B.
Story #7: I Still Hear the Screams
“This is a more sales-oriented story from a while back. A co-worker and I were on this call together; it was an introductory call with a nonprofit. They were looking to see what it would take to build a custom solution to merge all their separate custom systems., add new features, and make it available globally.
“When we got on this call, there was the nonprofit team and a random other third party that the nonprofit introduced as their software hiring consultant. This guy’s job is to help companies decide who they should hire for software development. It made sense: people who don’t know much about what is happening in software want to ensure they’re not getting scammed and better understand their options.
“As the call progressed, we learned more and more about the system’s complexity. By the end of the call, we had concluded that the problem was so complex that we would need to do a small discovery phase upfront before we could even get to a proposal. We do this a lot with overly complex solutions to ensure we understand the current solution, what new things need to be built, and what the priorities are.
“As we explained why we recommended this, the consultant cut us off and started screaming and yelling. He said we were trying to force a nonprofit to pay for a proposal, that we would just ‘make up’ everything in the discovery phase, and that we were a sham. He shouted that we were a horrible company and he would never recommend us to any of his future clients. The nonprofit team looked shocked by his outburst, and he ended the call without another word.
“Ultimately, the nonprofit decided not to proceed with any software update. I’m unsure how related it was to him, but that was definitely the most intense, confusing call I’ve ever been on.”
Conclusion
As we conclude this chilling journey through the realms of software horror, it’s clear that the development world is filled with its own brand of frights. We’ve witnessed the spine-tingling moment when sensitive data was exposed, the heart-wrenching experience of data corruption, and long hours with no end in sight.
So, dear readers, as you venture into the digital unknown, may you navigate cautiously, for in the shadows of the software world, the ghosts of software’s past may be waiting to haunt your every click and keystroke. Happy haunting, and may your tech nightmares stay firmly in your dreams. ??
