mikedao · February 10, 2015 15:41
diff --git a/gistfile1.txt b/gistfile1.txt
 Software Disasters

 For us, the worst that can happen when we write bad software is our app doesn't run. Maybe our website shows an error message.

 However, in the real world, it can get a lot worse.

 We're looking at two real world examples today where bad software, had really big real world implications

 Ariane 5

 Based on the Ariane 4 rocket, and took the European Space Agency ten years and $7 billion to produce.

 It was a big rocket, and was supposed to launch 4 satellites.

 It reused some components from the Ariane 4 a smaller and slower rocket.

 The Ariane 4 software took in a 16-bit number.

 An new piece of software that was supposed to talk to the older stuff tried to give it a 64 bit number, when all it could
 handle was a 16 bit number. For the more CS minded, it tried to convert a 64 bit float into a 16 bit signed integer. 

 39 seconds after launch it was clear something was wrong. And one of the staff hit the self destruct button in order to make sure no one was hurt from the failed launch.

 They never thought they would need a such a large number on rocket that was that slow. Until they reused that component in a larger, faster rocket.

 Cost: $370 million.

 Maybe they should have done an integration test.


 USS Yorktown CG-48

 Do all of your models have the appropriate validations?

 In 1997, the USS Yorktown was testing a new initiative where they would use off the shelf computers and software to save money.
 The plan was that they could cut crew by ten percent with automation and save $2.8 million a year. 

 So what happens when you try to divide by 0?

 A sailor accidentally entered 0 into a database field.

 The divide by zero error caused a buffer overflow.

 Don't blame the sailor, I mean how many typos have we made just this module alone so far?

 Cost: The USS Yorktown lost propulsion for over two hours.

 Maybe the database should have had some validations.

 Moral of the story: Test everything, and have good validations.
	Software Disasters

	For us, the worst that can happen when we write bad software is our app doesn't run. Maybe our website shows an error message.

	However, in the real world, it can get a lot worse.

	We're looking at two real world examples today where bad software, had really big real world implications

	Ariane 5

	Based on the Ariane 4 rocket, and took the European Space Agency ten years and $7 billion to produce.

	It was a big rocket, and was supposed to launch 4 satellites.

	It reused some components from the Ariane 4 a smaller and slower rocket.

	The Ariane 4 software took in a 16-bit number.

	An new piece of software that was supposed to talk to the older stuff tried to give it a 64 bit number, when all it could
	handle was a 16 bit number. For the more CS minded, it tried to convert a 64 bit float into a 16 bit signed integer.

	39 seconds after launch it was clear something was wrong. And one of the staff hit the self destruct button in order to make sure no one was hurt from the failed launch.

	They never thought they would need a such a large number on rocket that was that slow. Until they reused that component in a larger, faster rocket.

	Cost: $370 million.

	Maybe they should have done an integration test.


	USS Yorktown CG-48

	Do all of your models have the appropriate validations?

	In 1997, the USS Yorktown was testing a new initiative where they would use off the shelf computers and software to save money.
	The plan was that they could cut crew by ten percent with automation and save $2.8 million a year.

	So what happens when you try to divide by 0?

	A sailor accidentally entered 0 into a database field.

	The divide by zero error caused a buffer overflow.

	Don't blame the sailor, I mean how many typos have we made just this module alone so far?

	Cost: The USS Yorktown lost propulsion for over two hours.

	Maybe the database should have had some validations.

	Moral of the story: Test everything, and have good validations.