ollie mullin

It’s not the Computer’s Fault
Love Virus (2000)
It cost $8.75 billion dollars and millions of computers were infected along with significant data loss. The LoveLetter infected millions of people worldwide and had caused the largest damage of any virus in history. The bug deleted files, changed home pages and messed with the Registry.
It attacked via-email and sent an email with the subject of “ILOVEYOU”. When the user opened the message it would infect the computer and everyone else’s in the address book.
The LoveVirus could not have been prevented easily as soon as you opened the email. Once opened however you could delete the e-mail if the attachment file ended in .vbs (Visual Basic Script).
My conclusion is that the law in the Philippines didn’t cover this and therefore what the two men did wasn’t illegal so they technically in the wrong. Although what they did had huge consequences they weren’t jailed and many countries can learn the lesson.
Source: http://sandipsandilya.wordpress.com/2011/01/17/20-famous-software-disasters/

Mariner Bugs Out (1962)
The Mariner 1 rocket with a space probe headed for Venus changed the flight path it was meant to take only seconds after it launched. Mission Control destroyed the rocket 293 seconds after liftoff!
A programmer incorrectly transcribed a handwritten formula into computer code; he mistakenly missed a single superscript bar. Without the smoothing function indicated by the bar, the software treated normal variations of velocity as if they were serious, meaning all the faulty corrections sent the rocket flying off course.
This minute error proved one of the biggest and history and probably one of the most preventable too. If the programmer took a bit more care and proof checked it numerous times then the superscript bar would never have been missed and the rocket would have read the formula and continued on the correct path.
I will conclude this software error by saying that it is very rare it is the computer’s fault; especially in this case as the programmer incorrectly designed the script, the computer did exactly as it was asked and had the program been correct the computer would have followed it and stayed on the right path.

Sydney Cash Machine Glitch
Queues formed at cash machines in the Australian city of Sydney after they malfunctioned and began giving out large sums of money. More than 40 Commonwealth Bank cash machines across the city were affected by the problem. Officials said they were operating in stand-by mode, so could not identify the account balances of customers. The software went on stand-by because of a lack of staff keeping it running at that very one time and it took a while before they could reboot it back to normal
That meant that in some cases customers who had little or no money were able to withdraw large sums of cash. The technical glitch reportedly lasted for about five and a half hours.
Witnesses spoke of a queue of as many as 50 people at one particular cash machine in a Sydney suburb as word got out, Australian media said.
Problems were also reported in Melbourne.
"As a result of our problems today, some of our customers have gone to our ATMs and they've been able to withdraw more funds than they had in their account and therefore they've overdrawn their account," spokesman Bryan Fitzgerald told the Australian Broadcasting Corporation.
"We have a record of every transaction that's been made today and we'll be following up with our customers to make sure that we recover the funds they've overdrawn."
Police warned that it was an offence to keep money dispensed accidentally from a cash machine and urged people to return the cash.
"They should also realise that ATM locations are covered extensively by surveillance," Det Supt Col Dyson of New South Wales fraud squad said in a statement. Overall this was a big error and the bank should never allow a machine to go on standby mode even when the staff aren't keeping it updated and running. The operators changed this a few weeks later and many other small banks made sure it couldn't happen to them either.
USS Yorktown Incident
In the world of software development, there are several commonly known bugs that programmers encounter and have to cater for. One such example is the ‘divide by zero’ bug, where a calculation is performed that divides any number by zero. Such a calculation isn’t possible to resolve, at least not without using higher mathematics, and most software – for everything from super computers to pocket calculators – is written to take this scenario into account.
It was with some embarrassment, then, that the USS Yorktown suffered a complete failure of its propulsion system and was dead in the water for nearly 3 hours when a crew member typed a “0″ into the on-board database management system which was then used in a division calculation. The software was installed as part of a wider operation to use computers to reduce the man power needed to run some ships. Fortunately, the ship was engaged in maneuvers at the time of the incident, rather than deployed in a combat environment, which could have had more severe consequences.