Aaron N. Tubbs bio photo

Aaron N. Tubbs

Dragon chaser.

Twitter Facebook Google+ LinkedIn Github

For various political and practical reasons, 75-80% of the application incidents we file for my system get booked as “User Error” or “User Knowledge.” In all cases, there is something that the user failed to do, but nine times out of ten, it was a mistake the user should never have been able to make.

It is difficult for a system to say “actually, you traded security X with client Y, not client Z” if, for example, it has no actual knowledge of your trading book. I’ll grant that, that’s part of the 10% of user errors that I can safely say are user errors. On the other hand, if a user changes the structure of the portfolio, which behind the scenes causes an old link to be invalidated, and the user is never notified, we’re dealing with what I affectionately term a retarded situation. A retarded situation is situation in which a user has made a change that should not be possible, or they have made a change with side effects that are not immediately available. Here are some examples of retarded situations:

  • Lack of predefined values for limited-value inputs. For example, if there is a field to be entered for a date, you shouldn’t have to type in the date, when instead you can select the date with drop-down lists. Sure, it takes slightly longer to type 20041216 than 20041216, but the only thing you now have to worry about is entering invalid dates, which is a much easier check. Similarly, if you can only assign one of three options to a value, it should only be possible to enter those three values.
  • Complete lack of data validation. This is inexcusable. You should not be able to enter “Jack can’t develop crap” in a field that is supposed to hold the notional for a trade. Crashing with an exception or spitting out an error and not indicating the state of the transaction or what particular field was invalid is not sufficient. In the above example, you should be restricted to entering numbers only, and when you submit the value, it should indicate in a message like “notional entered is invalid” if something that doesn’t make sense is entered. Further.
  • Complete lack of bounds checking. If you know in a trade entry system that you can only book a trade on today’s date, being able to enter a trade date of ten years from now is not a good thing. Further, if you know that notional on your trades is entered in terms of millions, and that a valid range for trades is .5mm to 5,000mm, being able to enter a value of 1,000,000 (the user probably thinking they’re entering 1mm) is silly. Even if you don’t enforce a bound, providing a warning message in these situations (“Do you really want to book a trade notional of 10,000,000,000,000?”) would be swell.
  • Ability to individually change dependent pieces of information. If when you change item A, you must also change items B and C at the same time, or your data/system will becoming corrupt, it should be necessary to change all three items at the same time. Further, if you end up in a situation where there is an inconsistency between A, B, and C, the system should provide a general warning that there is a booking inconsistency.

Just the slightest bit of effort to do these sorts of things would instantly wash away most of our user error, which would reduce the risk to the business as well. Why is this so hard for the average developer? My ultimate point is that, nine times out of ten, a “user error” is actually a “programmer error.” That’s a shame.