Understanding the Problem
-
Probably the most insidious bugs to track down are the result of not understanding the problem, the way the customer does. This leads to all kinds of un-intended consequences. Lately, I have been converting an Excel spread sheet with tons of formulas and spreadsheet lookups to price our product into a data driven webservice that can be used by many applications instead of users indepenantly opening copies of this spreadsheet. Converting complex formulas from a spreadsheet without thoroughly understanding the intent of the original author is rife with logic bugs, all of the code works fine, it just doesn't provide the result the user was expecting, although the $2,000,000 markup per part was nice, it would be difficult to sell a $500 part for that. It turns out that there is a big difference between millimeters and inches! The pricing unit of measurement is static at inches (but this is not marked or noted on the spreadsheet anywhere), It was just common knowledge among the users to perform the critical step of converting units of measurement and corresonding values to inches prior to pricing!! So, when a 300mm Part went in for pricing, it priced as a 300 INCH PART! I guess what I am trying to say is make sure you understand the base processes you are modelling!
-
Probably the most insidious bugs to track down are the result of not understanding the problem, the way the customer does. This leads to all kinds of un-intended consequences. Lately, I have been converting an Excel spread sheet with tons of formulas and spreadsheet lookups to price our product into a data driven webservice that can be used by many applications instead of users indepenantly opening copies of this spreadsheet. Converting complex formulas from a spreadsheet without thoroughly understanding the intent of the original author is rife with logic bugs, all of the code works fine, it just doesn't provide the result the user was expecting, although the $2,000,000 markup per part was nice, it would be difficult to sell a $500 part for that. It turns out that there is a big difference between millimeters and inches! The pricing unit of measurement is static at inches (but this is not marked or noted on the spreadsheet anywhere), It was just common knowledge among the users to perform the critical step of converting units of measurement and corresonding values to inches prior to pricing!! So, when a 300mm Part went in for pricing, it priced as a 300 INCH PART! I guess what I am trying to say is make sure you understand the base processes you are modelling!
My rule of thumb when bug hunting: 1. Try find possible solution 2. Test solution 3. If more errors occur, you barking up the wrong tree, go look somewhere else, and goto step 1
**
xacc.ide-0.2.0.57 - now with C# 2.0 parser and seamless VS2005 solution support!
**
-
My rule of thumb when bug hunting: 1. Try find possible solution 2. Test solution 3. If more errors occur, you barking up the wrong tree, go look somewhere else, and goto step 1
**
xacc.ide-0.2.0.57 - now with C# 2.0 parser and seamless VS2005 solution support!
**
leppie wrote:
3. If more errors occur, you barking up the wrong tree, go look somewhere else, and goto
My first rule of debugging: "If you get a different error message you're making progress."
-
leppie wrote:
3. If more errors occur, you barking up the wrong tree, go look somewhere else, and goto
My first rule of debugging: "If you get a different error message you're making progress."
My first rule of debugging: "If you get a different error message you're making progress." Good one. Sometimes I like this: My first rule of debugging: "If you get an access violation you're making progress."
Any sufficiently gross incompetence is nearly indistinguishable from malice.