Difference between revisions of "Stop Foolish Rounding"

This page serves as the nexus for a community effort to stop foolish rounding of monetary values in business applications. Only a community will do because the roots of the problem run deep.

Founding Rant

I read a sophisticated email list where some of the best minds in software testing meet. Alan Jorgensen recently threw some dirt at software developers' feet on that list when he blamed them for the industry's failure to solve problems at their root cause:

I expect that there will be reluctance from the software development people for such methods are not consistent with the current software development culture. The idea of root cause analysis, for instance, is certainly alien to that culture. If your management team has been grown from software development, it will be a very hard sell.

I chose to defend programmers by citing an example where Jorgensen's for-instance, root cause analysis, was so often foiled by non-programmers that the real cause of many bugs has been taken off the table:

Root cause analysis, ha, ha, ha.

Allow me a brief rant. Consider the program:

a + b

This is a very failure prone program because it fails silently in many useful cases.

Root cause analysis would suggest that one should modify + to simply compute the right answer in all useful cases. This has been done by programmers over and over but these implementations of + are judged "odd ball" by management who would rather run a strict java or c# shop out of some weird distortion of the "prudent man" rule. (The prudent man rule says that you can't be accused of being reckless with your investor's money if you are doing the same thing everyone else does.)

I wrote financial software once and traced the root cause of difficult bugs to the implementation of + for data of types Date and Money. Fortunately I was programming in Smalltalk where the implementation of + was accessible. I took several days to correct these deficiencies after which my life, and that of my customers, became much better.

You might be thinking that there is nothing wrong with + and that Ward is just being cranky. I then say to you, you have not gone far enough in your root cause analysis.

And I say to business, who has selected and paid for most of today's computing infrastructure, you are fools for having funded 50 years of software and not yet gotten a + that works well for time or money.

I once advised an international company on how to implement a useful + for money. The developers loved it. The customers loved it. But the database didn't like it much at all. I met one of the developers a few years later. He asked, "do you have any idea how hard it is to persist that money abstraction to the database?" Yes, I had to admit that I knew it would be trouble but I also knew that they would get through it somehow once they got hooked on getting right answers in all of their money calculations.

(Aside: The database problem comes from the fact that the sum of a+b can take twice the storage of either a or b when a and b are international currency. This requires either a variable size storage mechanism or preallocation of space for hundreds of currencies. Databases favor neither solution. Again business has been fooled by the database vendors, not the programmers.)

I saw recently where the IEEE was proposing a standard for "decimal floating point" under the misguided believe that this would alleviate rounding errors. They are fools, for they attempted to do this within fixed sized storage, the one "feature" of floating a "point".

(Aside: The program a / b introduces additional potential errors which are again more correctly solved by variable allocation of storage than by "floating" a "point", decimal or otherwise.)'

I have intentionally stopped one sentence short of offering a complete solution in each of these cases. This is so that you can print this email and give it to the next Six Sigma guy that comes around as a test. Ask him to explain what I am talking about. If he gets it, ask him why he isn't hounding the vendors into fixing + instead of bothering you. If he doesn't get it, ask him how his methods are going to work on large programs when they can't find the bug in a + b.

(Aside: I heard that my financial software written for DOS is still in use today managing trillions of dollars. I also heard that the current owner/vendor was trying to meet customer demand by porting it to an industry standard database rather than the "odd ball" one I wrote for them. This porting effort was not going well. No surprise.)

You may need to read this post several times to get all the good advice that I've hidden between the sentences. I thank you for your attention. Best regards. -- Ward

Now I find myself in the position of having said, here is a problem and your solution doesn't work, without offering a solution myself. Thus this page. It may remain a public rant, like a blog post, or, it might seed the organization that takes on this persistent problem in computer software. I hope the latter. -- Ward 11:37, 8 September 2007 (PDT)

Floating Point Requirements Error

I hope I am aligning with the intent of this space. If not, whack it out.

I think that one of the reasons that this problem exists (a + b gets the wrong answer) is that the initial requirements for the design of floating point were simply incomplete. The missing element is "precision".

There needs to be a precision field in floating point representation that identifies the number of bits of precision still represented by the mantissa. This field should have a special value when the floating point value represented is an integer (i.e., there are as many bits of precision as are available). Otherwise the value should be the number of half-bits of precision still available. An operation requiring rounding should subtract one from this field. Normalization affects this field.

This doesn't solve the problems of adding currency objects (an n-dimensional space), but it would surely do a lot for "unstable" matrix calculations.

Alan Jorgensen 01:15, 13 September 2007 (PDT)

Call to Action

Um, what are we suppose to do about this?

Let's change both programming languages and database systems to have good representations for money. We may find that the shortest path to this goal is through the promotion of dynamic representations such as those Ward exploited in Smalltalk, and then using this capability to deliver good implementations of money.

Don't we have this already? Strangely no, not in the mainline languages and databases.

How do we proceed? I'm not sure. Let's start by following the script for organization formation offered below.

Clarifications

The storage space of the sum is the storage space of the less valued currency plus one digit. That does not imply that it needs twice as much storage. The programmer will normally assign a longer variable and that might be eventually one with a double space consumption. Especially in Smalltalk that would not be necessary if a special currency operation is programmed. -- Hans Hartmann

This would only be true if the quantities were fungible, which is not the case with mixed currencies. See Wikipedia on Fungibility. -- Ward

The plus one digit answer assumes something that I think Ward didn't assume, which is that one currency is converted into the other. However, doing that brings on a whole host of other problems, starting with: "Why did you pick that specific conversion rate and not another one?", and continuing with "How do you fix it if some big stakeholder decides that they don't like the rate you picked? All in all, I think I'd rather deal with the problems of doubling the field length. Those problems are much more tractable. -- Pat McGee

I understand your argument about fungibility, however I would not speak of an operator "+" in the meaning of addition. It would resort to adding apples and pears. -- Hans

I considered the problem very similar to the one of complex numbers where mathematicians do agree on the definition of +. In particular, if A = 5, and B = 6i, then A+B = (5, 6i). Likewise, if A = 100 USD, and B = 200 YEN, then A+B = (100 USD, 200 YEN). I had several hundred dimensions instead of complex number's two. This lead me to choose a variable sized representation. -- Ward

Awesome post. I only recently found out about machine epsilon (some things we learn WAY too late in life). I thought you might be interested in this paper: Mindless (pdf) -- Michael Bolton

Organization Formation

This page is an experiment in fomenting action. I'm expecting the process to proceed as follows:

• Individual has some passion for a subject, but not the energy to pursue it.
• Individual rants somewhere, then converts that rant to an organizational seed at AboutUs.
• Google finds the seed and introduces the page name into the internet's vocabulary.
• Individual spreads the rant around in many circles, suggests folks just google for it.
• A loose community forms around the page, with diverse ideas as to the way forward.
• The page, and mechanisms like Consensus Polling, tightens the community.
• The community acts yielding some positive result that wouldn't have happened any other way.

Six Sigma and Software Development Rant

Now I'm not saying that Six Sigma could be a good idea for Software Development and I am asserting that Six Sigma would be a hard hard sell in the software development community and a large reason for that is the current (non engineering oriented) software development culture.

But for a little background. After Ward posted the above "a + b" example and James Bach posted another comment, I posted a response also commenting on a problem I had trying to copy and paste from the Yahoo Groups email:

Of course we all use our own internal processes every day and when we do something wrong we sometimes understand what we did and why we did it so that we can avoid doing it again.

Take Ward's "a + b" example. My assumption here is that in some code, somewhere, this particular code failed. Once we know that, we know that the person who injected that code into the implementation did it for some reason. Part of that person's internal process. Not only that, that coder was following a set of rules that that person learned somewhere as the right set of rules to learn. (i.e., it is always safe to add to values of currency with "+"). But somewhere that person's internal process broke down and a mistake was made. So how can we avoid that particular mistake as a general practice? First of all, we'll need to know who did it. (Not likely.) Next, we'll need to find out why that person made that mistake (Not likely.) Then we would need to figure out how to establish a rule (or to provide training for an existing rule) so that our entire organization is unlikely to make that mistake again.:

These problems are buried in the software development culture. There are some very good efforts to change that culture (see the list of XP rules; my favorite is YAGNI, violation of which is a major source of errors), and to provide a uniform set of rules that everyone can follow. We can argue quality, but I know of no one who respects the quality of the software they are using (to their knowledge).

One universal rule of engineering practice: Sign your work.

When the developers at Microsoft tried doing this, what happened and why?

There seems to be a lot of disinformation about the nature of Six Sigma. For instance it is not about statistical control of inputs to ensure proper outputs but rather it is about:

• What defects appear in the product?
• How did they get there?
• What can we do to prevent that in the future?
• How can we ensure that the problem doesn't come back?

This is pretty much Six Sigma in a nutshell.

But I agree with James, it ain't going to happen, but like the TV commercial where the guy asks about all his women friends calling at the same time and taking down the phone system: "So it IS a possibility!"

Alan A. Jorgensen

BTW, I tried to copy Ward's comments into here and I couldn't do it. I'm using Thunderbird. Is that a bug?

Which elicited a question from Michael Bolton

Now, my question is: what would Six Sigma suggest that we do with this problem?

And that really tripped my trigger provoking the following rant designed to provide a detailed explanation of how Six Sigma could be applied to software development problems.

The first step in the Six Sigma process as I learned it is "Define". Just what is the problem, anyway? The starting place for me is the symptom of what I perceive to be a bug. I selected a section of the display. It was highlighted just like any other time I wanted to do a copy/paste operation. I tried Alt->Edit->Copy. Nothing bad seemed to happen. No warning that I haven't really copied. (No "Garbage In, Apology Out", and if selecting across a portion of two text boxes cannot be copied, or whatever the problem is, I expect to be told that I can't do what I am trying to do. Is that nuts?) When I subsequently did a paste; nothing happened. What did I do wrong? (I think Hendrickson pointed out that that is the first human response to a bug.) I tried CTRL+c. Nothing I know (that's easy) worked. In any case, having decided that that is a bug, or in reality, the symptom of a bug, somewhere there is code doing the wrong thing.

Maybe in this case it would be the failure to notify the user that this particular selection cannot be copied or that this string cannot be selected. Let's assume the former. Now, in Six Sigma, there is a problem: defining an "opportunity." There is a lot of flexibility in this area requiring a certain creativity. Indeed we are not necessarily counting apples and oranges but we do need to select something we can get a real handle on. In this example, perhaps we should select the nature of this bug: "Notification of an illegal user operation." Please keep in mind that this is only the first step, and later steps may prove our problem definition to be faulty or inadequate or overly difficult in some way.

Then in the next step, "Measure", we would have to count all of the times that our sample set should notify of illegality and the number of times that it does not. This ratio is our defect rate that we would like to drive to zero, but to be more practical, let's set the limit to a nearly impossible task, 3.4 defects per 1,000,000 opportunities. (Even more realistically, let's simply try to reduce the error rate by 80% on our first attempt and 50% thereafter until we achieve a defect rate of 0.034 per myriad (‱), one for which there is a meaningful name by which this entire process may be identified). As in any process, there is an art to properly applying it. Maybe, in order to make "Measure" easier, we simply want to define an "opportunity" as a function calling a function that returns an error code wherein the calling function does not examine or otherwise utilize the returned error code. Now I think that might prove to be a very useful quality statistic. As is often the case in Six Sigma, the problem we end up solving may not even be the one we originally set out to solve. But it is still a valid quality improvement. A fundamental assumption of Six Sigma is that defects cost real money and learning to avoid making the same mistakes produces tax free income in the form of money that does not need to be spent (cost avoidance). Done properly, the cost of quality is negative, not even counting the customer satisfaction benefits. Other cost avoidance techniques: "Let the customer test it for us." "Let's don't fix that bug."

And yes, there is a lot of complicated statistics involved, but I don't need to know why a car works in order to drive one (but it certainly helps, particularly when it doesn't, work, that is). Companies implementing Six Sigma have on-call Statistics Help Desks.

Then the next step, "Analyze", is to find all the reasons that we can for the failures; root cause analysis. We can use Pareto, or other techniques, to determine how many and which of those causes we need to fix in order to achieve our quality improvement goal. Then we need to put in place fixes for those particular causes. For instance, maybe the software designer didn't know that he or she was supposed to notify the user when the user attempted to do something the software couldn't do. Maybe training could fix that. Maybe the code was there, but didn't do its job correctly or warned in a way the user didn't notice, like commanding a sound when the sound is turned off. There are lots of ways of doing this poorly (as Ward pointed out). Or maybe we simply need to implant the rule: "Every function must return an error indicator and every function must process every error indicator returned by the functions it calls." Implementing the autonomic requirements makes this rule even more specific in terms of how returned errors must be processed. Having a standard way of doing this makes implementation and auditing much easier. (What? Audit MY work?)

In any case, the next step is "Implement" where all of the selected fixes need to be put into place.

The final step, "Control", is management's method of maintaining the fix which usually involves a policy that "Measurement" and "Analysis" continue periodically to ensure that the quality goal continues to be met with an action plan when it does not (like adding training for new hires).

Now if your marketing paradigm is to charge customers for fixing bugs, avoiding the creation of bugs is not your goal and Six Sigma is not for you.

Alan A. Jorgensen

Not in a Nutshell

"Garbage In, Apology Out"

This is really great. I have a lot more rants with real ideas about how to do something about them. At least there is this place to vent. Thank you, Ward.

Alan Jorgensen 23:22, 12 September 2007 (PDT)