Two Wrongs Can Make a Right (and Are Difficult to Fix) - Revision history

Allankelly at 08:32, 28 July 2009

2009-07-28T08:32:05Z

←Older revision		Revision as of 08:32, 28 July 2009
Line 1:		Line 1:
	Code never lies, but it can contradict itself. Some contradictions lead to those "How can that possibly work?" moments.		Code never lies, but it can contradict itself. Some contradictions lead to those "How can that possibly work?" moments.

-	In an [http://www.netjeff.com/humor/item.cgi?file=ApolloComputer interview], the principal designer of the Apollo 11 Lunar Module software, Allan Klumpp, disclosed that the software controlling the engines contained a bug which should have made the lander unstable. However, another bug compensated for the first and the software was used for Apollo 11 and 12 moon landings before ~~being~~ found ~~and~~ fixed.	+	In an [http://www.netjeff.com/humor/item.cgi?file=ApolloComputer interview], the principal designer of the Apollo 11 Lunar Module software, Allan Klumpp, disclosed that the software controlling the engines contained a bug which should have made the lander unstable. However, another bug compensated for the first and the software was used for Apollo 11 and 12 moon landings before either was found or fixed.

	Consider a function that returns a completion status. Imagine that it returns false when it should return true. Now imagine the calling function neglects to check the return value. Everything works fine until one day someone notices the missing check and inserts it.		Consider a function that returns a completion status. Imagine that it returns false when it should return true. Now imagine the calling function neglects to check the return value. Everything works fine until one day someone notices the missing check and inserts it.

Kevlin at 07:19, 28 July 2009

2009-07-28T07:19:58Z

←Older revision		Revision as of 07:19, 28 July 2009
Line 1:		Line 1:
	Code never lies, but it can contradict itself. Some contradictions lead to those "How can that possibly work?" moments.		Code never lies, but it can contradict itself. Some contradictions lead to those "How can that possibly work?" moments.
		+
		+	In an [http://www.netjeff.com/humor/item.cgi?file=ApolloComputer interview], the principal designer of the Apollo 11 Lunar Module software, Allan Klumpp, disclosed that the software controlling the engines contained a bug which should have made the lander unstable. However, another bug compensated for the first and the software was used for Apollo 11 and 12 moon landings before being found and fixed.

	Consider a function that returns a completion status. Imagine that it returns false when it should return true. Now imagine the calling function neglects to check the return value. Everything works fine until one day someone notices the missing check and inserts it.		Consider a function that returns a completion status. Imagine that it returns false when it should return true. Now imagine the calling function neglects to check the return value. Everything works fine until one day someone notices the missing check and inserts it.
Line 8:		Line 10:

	The interplay between two code defects that appear as one visible fault not only makes it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.		The interplay between two code defects that appear as one visible fault not only makes it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.
-
-	In an [http://www.netjeff.com/humor/item.cgi?file=ApolloComputer interview], the principal designer of the Apollo 11 Lunar Module software, Allan Klumpp, disclosed that the software controlling the engines contained a bug which should have made the lander unstable. However, another bug compensated for the first and the software was used for Apollo 11 and 12 moon landings before being found.

	This doesn't happen only in code: The problem also exists in written requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.		This doesn't happen only in code: The problem also exists in written requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.

Kevlin at 00:13, 24 July 2009

2009-07-24T00:13:55Z

←Older revision		Revision as of 00:13, 24 July 2009
Line 9:		Line 9:
	The interplay between two code defects that appear as one visible fault not only makes it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.		The interplay between two code defects that appear as one visible fault not only makes it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.

-	In an [http://www.netjeff.com/humor/item.cgi?file=ApolloComputer interview], the ~~Principal Designer~~ of the Apollo 11 Lunar Module software, Allan Klumpp, disclosed that the software controlling the engines contained a bug which should have made the lander unstable. However, another bug compensated for the first and the software was used for Apollo 11 and 12 moon landings before being found.	+	In an [http://www.netjeff.com/humor/item.cgi?file=ApolloComputer interview], the principal designer of the Apollo 11 Lunar Module software, Allan Klumpp, disclosed that the software controlling the engines contained a bug which should have made the lander unstable. However, another bug compensated for the first and the software was used for Apollo 11 and 12 moon landings before being found.

	This doesn't happen only in code: The problem also exists in written requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.		This doesn't happen only in code: The problem also exists in written requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.

Kevlin at 00:13, 24 July 2009

2009-07-24T00:13:22Z

←Older revision		Revision as of 00:13, 24 July 2009
Line 9:		Line 9:
	The interplay between two code defects that appear as one visible fault not only makes it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.		The interplay between two code defects that appear as one visible fault not only makes it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.

-	In an [[http://www.netjeff.com/humor/item.cgi?file=ApolloComputer interview]], the Principal Designer of the Apollo 11 Lunar Module software, Allan Klumpp, disclosed that the software controlling the engines contained a bug which should have made the lander unstable. However, another bug compensated for the first and the software was used for Apollo 11 and 12 moon landings before being found.	+	In an [http://www.netjeff.com/humor/item.cgi?file=ApolloComputer interview], the Principal Designer of the Apollo 11 Lunar Module software, Allan Klumpp, disclosed that the software controlling the engines contained a bug which should have made the lander unstable. However, another bug compensated for the first and the software was used for Apollo 11 and 12 moon landings before being found.

	This doesn't happen only in code: The problem also exists in written requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.		This doesn't happen only in code: The problem also exists in written requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.

Kevlin at 00:12, 24 July 2009

2009-07-24T00:12:51Z

←Older revision		Revision as of 00:12, 24 July 2009
Line 9:		Line 9:
	The interplay between two code defects that appear as one visible fault not only makes it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.		The interplay between two code defects that appear as one visible fault not only makes it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.

-	In an ~~interview with the Principle Designer of the Apollo 11 Lunar Module software, Allan Klumpp,~~ http://www.netjeff.com/humor/item.cgi?file=ApolloComputer, disclosed that the software controlling the engines contained a bug which should have made the lander unstable. However, another bug compensated for the first and the software was used for Apollo 11 and 12 moon landings before being found.	+	In an [[http://www.netjeff.com/humor/item.cgi?file=ApolloComputer interview]], the Principal Designer of the Apollo 11 Lunar Module software, Allan Klumpp, disclosed that the software controlling the engines contained a bug which should have made the lander unstable. However, another bug compensated for the first and the software was used for Apollo 11 and 12 moon landings before being found.

	This doesn't happen only in code: The problem also exists in written requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.		This doesn't happen only in code: The problem also exists in written requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.

Allankelly at 17:44, 23 July 2009

2009-07-23T17:44:19Z

←Older revision		Revision as of 17:44, 23 July 2009
Line 8:		Line 8:

	The interplay between two code defects that appear as one visible fault not only makes it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.		The interplay between two code defects that appear as one visible fault not only makes it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.
		+
		+	In an interview with the Principle Designer of the Apollo 11 Lunar Module software, Allan Klumpp, http://www.netjeff.com/humor/item.cgi?file=ApolloComputer, disclosed that the software controlling the engines contained a bug which should have made the lander unstable. However, another bug compensated for the first and the software was used for Apollo 11 and 12 moon landings before being found.

	This doesn't happen only in code: The problem also exists in written requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.		This doesn't happen only in code: The problem also exists in written requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.

Kevlin: Two wrongs can make a right (and are difficult to fix) moved to Two Wrongs Can Make a Right (and Are Difficult to Fix)

2009-07-13T12:19:54Z

Two wrongs can make a right (and are difficult to fix) moved to Two Wrongs Can Make a Right (and Are Difficult to Fix)

←Older revision

Revision as of 12:19, 13 July 2009

Kevlin at 12:19, 13 July 2009

2009-07-13T12:19:32Z

←Older revision		Revision as of 12:19, 13 July 2009
Line 5:		Line 5:
	Or consider an application that stores state as an XML document. Imagine that one of the nodes in incorrectly written as <code>TimeToLive</code> instead of <code>TimeToDie</code>, as the documentation says it should. Everything appears fine while the writer code and the reader code both contain the same error. But fix one, or add a new application reading the same document, and the symmetry is broken, as well as the code.		Or consider an application that stores state as an XML document. Imagine that one of the nodes in incorrectly written as <code>TimeToLive</code> instead of <code>TimeToDie</code>, as the documentation says it should. Everything appears fine while the writer code and the reader code both contain the same error. But fix one, or add a new application reading the same document, and the symmetry is broken, as well as the code.

-	When two defects in the code create one visible fault, the methodical approach to fixing faults can itself break down. The developer gets a bug report, finds the defect, fixes it, and retests. ~~However the~~ reported fault still occurs ~~—~~ because a second defect is at work. So the first fix is removed, the code inspected until the second underlying defect is found, and a fix applied for that. But the first defect has returned, the reported fault is still seen, and so the second fix is rolled back. The process repeats but now the developer has dismissed two possible fixes and is looking to make a third that will never work.	+	When two defects in the code create one visible fault, the methodical approach to fixing faults can itself break down. The developer gets a bug report, finds the defect, fixes it, and retests. The reported fault still occurs, however, because a second defect is at work. So the first fix is removed, the code inspected until the second underlying defect is found, and a fix applied for that. But the first defect has returned, the reported fault is still seen, and so the second fix is rolled back. The process repeats but now the developer has dismissed two possible fixes and is looking to make a third that will never work.

	The interplay between two code defects that appear as one visible fault not only makes it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.		The interplay between two code defects that appear as one visible fault not only makes it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.

-	This doesn't ~~only~~ happen in code: ~~the~~ problem also exists in written requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.	+	This doesn't happen only in code: The problem also exists in written requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.

	It can spread to people too: users learn that when the application says ''Left'' it means ''Right'', so they adjust their behavior accordingly. They even pass it on to new users: "Remember when that applications says click the left button it really means the button on the right." Fix the bug and suddenly the users need retraining.		It can spread to people too: users learn that when the application says ''Left'' it means ''Right'', so they adjust their behavior accordingly. They even pass it on to new users: "Remember when that applications says click the left button it really means the button on the right." Fix the bug and suddenly the users need retraining.

Kevlin at 08:16, 2 February 2009

2009-02-02T08:16:01Z

←Older revision		Revision as of 08:16, 2 February 2009
Line 3:		Line 3:
	Consider a function that returns a completion status. Imagine that it returns false when it should return true. Now imagine the calling function neglects to check the return value. Everything works fine until one day someone notices the missing check and inserts it.		Consider a function that returns a completion status. Imagine that it returns false when it should return true. Now imagine the calling function neglects to check the return value. Everything works fine until one day someone notices the missing check and inserts it.

-	Or consider an application that stores state as an XML document. Imagine that one of the nodes in incorrectly written as TimeToLive instead of TimeToDie, as the documentation says it should. Everything appears fine while the writer code and the reader code both contain the same error. But fix one, or add a new application reading the same document, and the symmetry is broken, as well as the code.	+	Or consider an application that stores state as an XML document. Imagine that one of the nodes in incorrectly written as <code>TimeToLive</code> instead of <code>TimeToDie</code>, as the documentation says it should. Everything appears fine while the writer code and the reader code both contain the same error. But fix one, or add a new application reading the same document, and the symmetry is broken, as well as the code.

-	When two ~~faults~~ in the code create one visible fault the methodical approach to fixing faults itself ~~breaks~~ down. The developer gets a ~~fault~~ report, finds ~~a fault~~, fixes ~~the fault~~ and retests. However the reported fault still occurs – because a second ~~fault~~ is at work. So the first fix is removed, the code inspected until the second underlying ~~fault~~ is found and a fix applied for that. But the first ~~fault~~ has returned, the reported fault is still seen and so the second fix ~~and~~ rolled back. The process repeats but now the developer has dismissed two possible fixes and is looking to make a third that will never work.	+	When two defects in the code create one visible fault, the methodical approach to fixing faults can itself break down. The developer gets a bug report, finds the defect, fixes it, and retests. However the reported fault still occurs — because a second defect is at work. So the first fix is removed, the code inspected until the second underlying defect is found, and a fix applied for that. But the first defect has returned, the reported fault is still seen, and so the second fix is rolled back. The process repeats but now the developer has dismissed two possible fixes and is looking to make a third that will never work.

-	The interplay between two code ~~faults~~ that appear as one visible fault not only ~~make~~ it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.	+	The interplay between two code defects that appear as one visible fault not only makes it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.

-	This doesn't only happen in code: the problem also exists in ~~writen~~ requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.	+	This doesn't only happen in code: the problem also exists in written requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.

-	It can spread to people too: users learn that when the application says Left it means Right, so they adjust their ~~behaviour~~ accordingly. They even pass it on to new users: "Remember when that applications says click the left button it really means the button on the right." Fix the bug and suddenly the users need retraining.	+	It can spread to people too: users learn that when the application says ''Left'' it means ''Right'', so they adjust their behavior accordingly. They even pass it on to new users: "Remember when that applications says click the left button it really means the button on the right." Fix the bug and suddenly the users need retraining.

-	Single wrongs can be easy to spot and easy to fix. It is the problems ~~that need~~ multiple changes that are harder to resolve. In part it is because easy problems are so easily fixed that people tend to fix them relatively quickly and store up the more difficult problems for a ~~late~~ date.	+	Single wrongs can be easy to spot and easy to fix. It is the problems with multiple causes, needing multiple changes, that are harder to resolve. In part it is because easy problems are so easily fixed that people tend to fix them relatively quickly and store up the more difficult problems for a later date.

-	There is no simple advice to give on how to address ~~multiple~~ faults. Awareness of the possibility, a clear head and a willingness to consider all possibilities is needed.	+	There is no simple advice to give on how to address faults arising from sympathetic defects. Awareness of the possibility, a clear head, and a willingness to consider all possibilities is needed.

	By [[Allan Kelly]]		By [[Allan Kelly]]

Allankelly at 14:19, 1 February 2009

2009-02-01T14:19:37Z

←Older revision		Revision as of 14:19, 1 February 2009
Line 1:		Line 1:
-	Code never lies~~. But~~ it can contradict itself. Some contradictions lead to those "How can that possibly work?" moments.	+	Code never lies, but it can contradict itself. Some contradictions lead to those "How can that possibly work?" moments.

	Consider a function that returns a completion status. Imagine that it returns false when it should return true. Now imagine the calling function neglects to check the return value. Everything works fine until one day someone notices the missing check and inserts it.		Consider a function that returns a completion status. Imagine that it returns false when it should return true. Now imagine the calling function neglects to check the return value. Everything works fine until one day someone notices the missing check and inserts it.
Line 5:		Line 5:
	Or consider an application that stores state as an XML document. Imagine that one of the nodes in incorrectly written as TimeToLive instead of TimeToDie, as the documentation says it should. Everything appears fine while the writer code and the reader code both contain the same error. But fix one, or add a new application reading the same document, and the symmetry is broken, as well as the code.		Or consider an application that stores state as an XML document. Imagine that one of the nodes in incorrectly written as TimeToLive instead of TimeToDie, as the documentation says it should. Everything appears fine while the writer code and the reader code both contain the same error. But fix one, or add a new application reading the same document, and the symmetry is broken, as well as the code.

-	When two faults in the code create one visible fault the methodical approach to fixing faults itself breaks down. The developer gets a fault report, finds a fault, fixes the fault and retests. However the fault ~~reoccurs~~ – because a second fault is at work. So the first fix is removed, the code inspected until the second fault is found and a fix applied for that. But the first fault has returned so the second fix ~~is inconclusive~~ and rolled back. The process repeats but now the developer has dismissed two possible fixes and is looking to make a third that will never work.	+	When two faults in the code create one visible fault the methodical approach to fixing faults itself breaks down. The developer gets a fault report, finds a fault, fixes the fault and retests. However the reported fault still occurs – because a second fault is at work. So the first fix is removed, the code inspected until the second underlying fault is found and a fix applied for that. But the first fault has returned, the reported fault is still seen and so the second fix and rolled back. The process repeats but now the developer has dismissed two possible fixes and is looking to make a third that will never work.

	The interplay between two code faults that appear as one visible fault not only make it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.		The interplay between two code faults that appear as one visible fault not only make it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.

-	This doesn't only happen in code: the problem also exists in ~~write~~ requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.	+	This doesn't only happen in code: the problem also exists in writen requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.

	It can spread to people too: users learn that when the application says Left it means Right, so they adjust their behaviour accordingly. They even pass it on to new users: "Remember when that applications says click the left button it really means the button on the right." Fix the bug and suddenly the users need retraining.		It can spread to people too: users learn that when the application says Left it means Right, so they adjust their behaviour accordingly. They even pass it on to new users: "Remember when that applications says click the left button it really means the button on the right." Fix the bug and suddenly the users need retraining.
Line 15:		Line 15:
	Single wrongs can be easy to spot and easy to fix. It is the problems that need multiple changes that are harder to resolve. In part it is because easy problems are so easily fixed that people tend to fix them relatively quickly and store up the more difficult problems for a late date.		Single wrongs can be easy to spot and easy to fix. It is the problems that need multiple changes that are harder to resolve. In part it is because easy problems are so easily fixed that people tend to fix them relatively quickly and store up the more difficult problems for a late date.

-	There is no simple advice to give on how to address multiple faults. Awareness of the possibility, a clear head and a willingness to consider possibilities is needed.	+	There is no simple advice to give on how to address multiple faults. Awareness of the possibility, a clear head and a willingness to consider all possibilities is needed.

	By [[Allan Kelly]]		By [[Allan Kelly]]