Author: Louise Pryor

News update 2006-06: June 2006
===================

Contents:
1. Software in ICAs
2. The proof of the pudding is in the testing
3. Portable insecurity
4. Sharing spreadsheets
5. Newsletter information

===============
1. Software in ICAs

Many thanks to everyone who has completed the online survey about
software use in ICAs, at http://www.louisepryor.com/survey.html

If you are involved in the ICA process, at whatever level, I’d
appreciate it if you could fill the survey in: it should only take
about a quarter of an hour, and the more responses there are the
more useful the results will be. All participants will get a full
analysis of the results, and responses are confidential.

The survey concentrates on an overview of what types of software
are used in ICAs, and the general level of systems and controls
that are in place. Responses saying that you don’t know are equally
as valuable as those that give rankings. I hope that the results of
the survey will provide an impression of the general level of
confidence in existing systems and controls, and how broad the
range of practice is. It will also be interesting to see how much,
if at all, practice differs between life and non-life insurance
companies.

Here’s that link again: http://www.louisepryor.com/survey.html

===============
2. The proof of the pudding is in the testing

Why should you test software? It’s time consuming, and therefore
often expensive. If you could prove that a program was correct,
surely you wouldn’t need to test it. And maybe a thorough review of
the code would mean that you wouldn’t need to run thorough tests.

Dream on. It would be lovely if it were true, but it ain’t, as two
recent episodes demonstrate.

An algorithm that has been accepted as correct for years (proved in
a book in 1986; probably proved elsewhere before that) has been
found to have a bug. It’s a widely used sorting algorithm, that’s
been used in many different places, including the implementation of
Java. It only fails in somewhat unusual circumstances, when you’re
sorting an array of more than about 2^30 elements (that’s about a
billion). When the proof was published, back in the 1980’s, the
idea of sorting such large arrays was inconceivable. The bug was
recently reported after being encountered in practice in Java, nine
years after the relevant code was released, and 20 years after the
proof.

So what went wrong? The algorithm contains the following line:

int mid =(low + high) / 2;

which takes the average of two numbers, and truncates it to an
integer. This doesn’t work when the sum of low and high is greater
than the maximum positive integer value (2^32 – 1). In this case
the sum overflows to a negative number, and all hell breaks loose
(or at least exceptions are thrown or unpredictable things occur,
depending on the programming language).

There are some simple ways of changing this line so that it always
works: for example,

int mid = low + ((high – low) / 2);

works as long as both high and low are positive integers less than
2^32 – 1, and high is greater than low (which is guaranteed
elsewhere in the algorithm).

http://lawyclic.notlong.com

The proof relied on implicit assumptions about the size of the
array being sorted. Those assumptions held in practice at the time
that the proof was first published, but have become unrealistic in
the years since that time. A proof always relies on assumptions,
and can only be trusted as far as the assumptions hold in
practice. As Yogi Berra once said: In theory there is no difference
between theory and practice; in practice, there is. Which is why
there is no substitute for actually testing the practical
implementation.

http://www.brainyquote.com/quotes/authors/y/yogi_berra.html

This is a lesson that NASA engineers have learned to their
cost. The Genesis space probe crashed in 2004, as it was bringing
back solar wind particles for analysis. Its parachutes failed to
open, because the gravity switches that should have operated them
were installed backwards.

There was a test that would have uncovered the fatal flaw, but it
wasn’t performed because of time constraints. It was thought that
comparing the design drawings to those of a previous, successful,
spacecraft, would do instead.

http://edition.cnn.com/2006/TECH/space/06/14/genesis.crash.ap/index.html

Again, this shows up the risks of relying on theory rather than
practice. Comparing the design drawings assumes that the
implementation (in this case, the physical spacecraft) corresponds
exactly to the theoretical model (the design drawings). This is a
big assumption to make, and in this case it turned out to be
unrealistic.

I see the same pattern occurring with spreadsheets and other user
developed software, including actuarial models. Even if the
specification is correct, the implementation may not be; and a
thorough review of the code doesn’t guarantee that it will work in
practice. Code reviews and theoretical proofs have a role to play,
of course, but can’t replace proper testing of the actual
implementation.

If you’d like help in setting up a systematic testing process for
your user developed software, just let me know by replying to this
email, or contacting me through my web site at

Climate change actuary

===============
3. Portable insecurity

There are (or should be) some very red faces at the Federal Trade
Commission, the US body responsible for protecting citizens from
identity theft and fraud. Two FTC laptops, containing the personal
details of 110 people, have been stolen.

http://www.out-law.com/page-7032

This is just the latest in a long string of stories about stolen
laptops containing personal details: just enter “laptop personal
data” into Google to see some of them.

http://www.google.co.uk/search?q=laptop+personal+data

40,000 BP workers on an Ernst and Young laptop… 13,000 people on
an ING laptop… 243,000 hotel guests… 68,000 YMCA
members… it’s a lot of people. In many cases the laptops were
probably stolen as hardware, rather than for the information they
held, but that doesn’t really lessen the risk. In some of these
cases we are told that the information was password protected, but
that may not mean much. The password protection in Excel, for
example, is notoriously weak. There are any number of tools
available to crack Excel passwords.

http://www.google.co.uk/search?q=excel+password+cracking

All the stories we read in the press are about the loss of laptops
containing personal details, but I’m willing to bet that there are
a lot of laptops out there that contain highly confidential
business information: business plans, marketing plans, ICA
calculations, and so on. Now, it may be rational behaviour: the
chance of losing a laptop is actually quite small, and the chance
that the casual thief would be interested in such information, or
know what to do with it, must be even smaller.

The circumstances surrounding all these incidents will vary, but I
imagine that in at least some of them security guidelines were
breached. Company guidelines may limit the type of information that
can go onto laptops, but that doesn’t necessarily stop people
putting it there. Their own convenience wins out. When it comes
down to it, all the guidelines in the world aren’t going to make a
difference if they are ignored by the people on the ground. In
fact, this is just part of a wider problem: many security breaches
are not technology driven at all, but happen because people write
their passwords down, leave laptops lying around, or otherwise
lower their guard.

What looks like an interesting book, “Information Security and
Employee Behaviour,” discusses the issues involved and presents
some solutions. From the review I have read it takes a fairly
balanced view, discussing why why security people get fixated on
their field, and often over-emphasise minor problems. As with all
areas of risk management, one of the problems is that people just
aren’t very good at assessing risk.

http://catless.ncl.ac.uk/Risks/24.33.html#subj21.1

Another problem is that the risk to the laptop owner is not the
same as the risk to the people whose personal details are on the
laptop. Identity theft is both disturbing and time consuming to
fix, for the victims, but losing a laptop, while annoying, doesn’t
really have the same effect.

Aligning Interest with Capability

===============
4. Sharing spreadsheets

It’s all go on the spreadsheet front at the moment, with Microsoft
releasing a white paper on the next version of Excel (see last
month’s newsletter) and Google Spreadsheets making an appearance.

http://spreadsheets.google.com/

Here’s what Google says about Google Spreadsheets:

1. Share spreadsheets instantly & collaborate real-time.
– Pick exactly who can access your spreadsheets.
2. Edit your spreadsheets from anywhere.
– Nothing to download — your browser is all you need.
3. Store your spreadsheets securely online.
– Offsite storage plus multi-site data backup.
4. Easy to use.
– Import your current spreadsheets to get started quickly.
– Clean, uncluttered screens with a familiar, desktop.

All this sounds good, but there are some drawbacks.

First, the functionality isn’t complete. It’s a pretty basic
spreadsheet, which is fair enough for a first release. It seems to
have all the same actual functions as Excel, but has no macros, you
can’t print your spreadsheets out, there’s only limited formatting
(no cell borders, no conditional formatting), no defined Names, no
data tables, no pivot tables, no objects (charts, text boxes,
shapes, etc) …

Some of these omissions are undoubtedly because of the limitations
of browser technology. You just can’t manage the user interface
through a browser in the same way that you can with a purpose built
application.

Second, it doesn’t work with all browsers yet. It’s fine with
Firefox and Internet Explorer, but Opera isn’t supported. I suspect
that it doesn’t work well with text to speech software, either.

Third, there’s the security problem. The spreadsheets are stored
on Google’s servers. Whatever the safeguards, it’s just not the
same as having them on your own machines.

Fourth, it’s all very well sharing a spreadsheet, and there is some
control in that the creator is the only person who can give other
people access (either read-only or editing), but once you have
several people being able to change a spreadsheet you want to be
able to track the changes. Of course, this is a drawback with
Excel, too, but the problem will (apparently) be addressed in the
next release.

For a first release, though, it’s pretty impressive, and easy to
use. No doubt they’ll come up with some ways of addressing some of
the functionality issues. The sharing is particularly good for
collaborative working, with a chat window so that you can talk
about the changes you are making.

It wouldn’t surprise me if it was eventually sold for use on
company intranets, which would deal with the security issue. And
with some sort of version control, so you could lock down a version
after a spell of collaborative work, and assuming that they find a
way to add more functionality, it could be very useful.

===============
5. Newsletter information

This is a monthly newsletter on risk management in financial
services, operational risk and user-developed software from Louise
Pryor (http://www.louisepryor.com). Copyright (c) Louise Pryor
2006. All rights reserved. You may distribute it in whole or in
part as long as this notice is included.

To subscribe, email news-subscribe AT louisepryor.com. To
unsubscribe, email news-unsubscribe AT louisepryor.com. Send all
comments, feedback and other queries to news-admin AT
louisepryor.com. (Change ” AT ” to “@”). All comments will be
considered as publishable unless you state otherwise. The
newsletter is archived at http://www.louisepryor.com/newsArchive.do.

News update 2006-05: May 2006
===================

Contents:
1. Software in ICAs
2. Spreadsheet compliance
3. Crying wolf
4. Accountability
5. Newsletter information

===============
1. Software in ICAs

Over the last few years there have been some big changes in how
insurance companies are run, not the least of which has been the
introduction of ICAs, or Individual Capital Assessments. Insurance
companies now have to calculate the risk-based capital they believe
they need; the result of the calculation is used by the FSA in the
determination of the company’s ICG, or Individual Capital Guidance,
which is the level of capital that the FSA believes they need. The
ICA calculation is now a very important one to most insurance
companies, and is treated very seriously.

Each company approaches their ICA calculation in a slightly
different way, but the one thing that all the calculations have in
common is that they use end-user software: software such as
actuarial models and spreadsheets that is developed by the
end-user, rather than farmed out to the IT department. But what
software? And how is it being used?

That’s where you can help. If you are involved in producing an ICA
for an insurance company, whether it’s a life or non-life company,
whether you are running the whole ICA effort or are a cog (but
all cogs are vital) in a well-oiled machine, or anything in
between, please take part in my online survey. You’ll find it at
http://www.louisepryor.com/show.do?page=ICAsurvey, and it should
only take about 10 minutes of your time. All participants will
receive a full analysis of the results.

The survey looks at what software is being used, and, equally
importantly, the systems and controls that are in place around
it. The FSA has stressed that the systems and controls are
important: it’s no use simply producing a number and expecting it
to be believed, you’ve got to be able to give the reasons why other
people should have confidence in your results. Other people might
entertain doubts about their validity unless you can:

– demonstrate a full audit trail from data and parameters through
to the final results
– provide details of the tests and reviews that your models have
passed
– demonstrate that the results come from the versions of your
models that have passed the tests and reviews
– provide clear documentation of your models, including the
assumptions on which they are based

I’ve written a brief paper on ‘How to believe your models’, which
is available at http://www.louisepryor.com/papers/confident.pdf.

The survey should provide some idea of the current levels of
systems and controls that are in place. If you take part, you’ll be
able to compare your standards with those of your peers
(anonymously, of course).

http://www.louisepryor.com/show.do?page=ICAsurvey

===============
2. Spreadsheet compliance

I would not be at all surprised to learn that spreadsheets are used
in the preparation of every single ICA. In fact, I’d be interested
to hear of an ICA whose calculation didn’t involve a spreadsheet;
and if I was told of one, I’d want to trace all the calculations
through from start to finish before I believed it. There is no
doubt that spreadsheets are a vital tool in business today, and
that the most widely used spreadsheet is Microsoft’s Excel.

Over the years many people have pointed out that although Excel is
used for many mission critical applications, it is extremely
difficult to apply the same systems and controls to spreadsheets as
one would to more conventionally developed software. Of course,
Excel is by no means the only end-user software in this position.

However, it appears that the situation is going to change. There’s
a new version of Excel due out next year, and Microsoft have
recently issued a White Paper that discusses some of the new
features that it will contain. It is called “Spreadsheet Compliance
in the 2007 Microsoft Office System” and can be found at
http://makeashorterlink.com/?T2464203D. There’s a blog entry about
it at http://blogs.msdn.com/excel/archive/2006/05/12/596605.aspx.
The paper is definitely recommended reading. It’s good to see that
Microsoft are taking compliance issues seriously.

The paper, quite rightly, stresses the importance of having good
process in place. “One common misconception in organisations is
that spreadsheet compliance can be achieved through the use of
technology. While technology plays a role in any compliance
strategy, the most important component is process. Critical
spreadsheets and other enterprise IT resources require sound
development and usage practices that include controlled testing,
deployment, maintenance, and use.” Having said that, and after
describing some of the elements of a good process, it goes on to
describe new features in Excel and Office that will support a sound
process. To me, one of the most interesting is good support for
versioning. It will also be much easier to restrict the circulation
of spreadsheets, based on whether they have been approved for wider
use. There will be other new features within Excel that are
intended to make it easier to use consistent coding practices and
standards while developing and maintaining spreadsheets.

Obviously, it remains to be be seen how easy it will be to make use
of all this new functionality in practice. And however easy it is,
there will have to be a willingness to use it if working practices
are to change. Moreover, given that there is still a significant
proportion of people using Excel 97, we have to wonder what the
take-up rate of Excel 2007 will be.

Brandon Weber of Microsoft will be giving a talk on some of the
issues and features discussed in the White Paper at the EuSpRIG
conference in Cambridge at the beginning of July. His talk fits in
nicely with the theme of this year’s conference, which is ‘Managing
Spreadsheets: Improving corporate performance, compliance and
governance’. Other topics covered by papers that will be presented
at the conference include:

– Assessing current spreadsheet use
– Risk and other classification systems
– Proving effectiveness
– Available control techniques
– Planning which kind of techniques fit which risks
– Maintaining integrity and compliance
– Discovering and promoting training resources and good practice

Full details of the conference, including a registration form, are
at http://www.uwic.ac.uk/eusprig/2006/index.htm. Early registration
is advised, as accommodation in Cambridge is scarce and expensive at
that time of year.

Although the forthcoming enhancements to Excel are very welcome,
they are not here yet, and people are using Excel now, at this very
moment. Waiting until next year in order to implement basic systems
and controls is not an option. Some organisations are using Excel
competently, but many more are either complacent or compromised.
Which are you? Take a 30 second quiz to find out, at
http://www.louisepryor.com/show.do?page=quiz

===============
3. Crying wolf

Every so often there’s a furore about cash machines charging people
to withdraw cash; popular opinion is pretty firm that they should
be free. According to a recent survey a surprising number of users
don’t realise that they’ve been charged a fee even when they’ve
been warned on the screen and have had to confirm their acceptance
of the charge — up to 15% of users.

http://www.finextra.com/fullstory.asp?id=15264

But is it surprising? Often people are multi-tasking as they take
cash out: carrying on a conversation, chatting on their mobile, or
thinking about what they are going to do with the money. Besides,
many of the machines that charge are in pubs or clubs, so their
users aren’t necessarily on tip-top intellectual form. We all know
how easy it is to click on things on the screen without really
taking them in; it happens all the time with warning screens in
desktop applications. Are you sure you want to open rather than
save? Are you sure you want to delete this? It’s all too easy to
use the default options without thinking, and find that you have
overwritten a vital file or lost important information.

There isn’t really any reliable way of making sure that the user is
doing what they intend to. Thought reading would be nice, but just
isn’t possible. We have WYSIWYG (What You See Is What You Get)
interfaces, but DWIM (Do What I Mean) interfaces are still a long
way off. Good interface design is hard.

Many of the big computer error stories that make it through to the
headlines are actually stories about the risks of poorly designed
interfaces: ones that lack data validation, reasonableness checks,
or just make it too easy to do the wrong thing. But even well
designed interfaces aren’t going to eliminate all mistakes; all
they can do is reduce the risks. Too many warnings can be as
dangerous as too few.

Just to make the obvious point, interface design is important in
end-use computing, too. If someone else is going to use your
spreadsheet, have you make it obvious what information they should
enter? Is the information checked for reasonableness? Do you make
it hard for other users to overwrite vital calculations, or miss
important parameters? If you have a sneaking suspicion that your
spreadsheets or other user-developed applications could use some
improvement, please contact me either by replying to this email or
through my web site at
http://www.louisepryor.com/show.do?page=contact.

===============
4. Accountability

Australian bank ANZ suffered a major credit card processing failure
earlier this year: 200,000 credit card holders were accidentally
charged twice. They refunded A$45 million to those who were
affected. Although there was some publicity, it’s unlikely that
their reputation will suffer unduly: none of the card holders in
question were their own customers. The problem affected only
non-ANZ cardholders using ANZ eftpos terminals. Transactions for
ANZ cardholders were handled by a different database, which was
operating normally.

A normal customer, paying by credit card in a shop, isn’t aware
who supplies the eftpos machine they are using. From their point of
view, they are dealing with the shop, or with their own credit card
issuer. When problems arise, those are the people who are going to
get the blame. Indeed, one report mentioned that many cardholders
were blaming the retailers — who of course had nothing to do with
it.

It is often thought that one of the drivers for good customer
service is the reaction of customers: bad service will drive them
away. How does that work in a case like this? I think the pressure
is still there, but at second hand, and somewhat attenuated. It is
the retailers who are ANZ’s customers; it’s the retailers who got
bad feedback from the cardholders; and it will be the retailers who
vote with their feet, by changing to another bank for their eftpos
facilities. Of course it’s not as easy as all that to change, as
eftpos is just one among many services that small businesses get
from their banks. If the affected cardholders had been ANZ
customers directly, it’s likely that some of them would have
switched to different cards, which is altogether easier than a
retailer switching to another eftpos provider.

So, to some extent, the moral of the story, if you are in the
credit card business, is to make sure that any problems don’t
affect your own cardholders. Indeed, in this situation it’s
possible that some cardholders will change card issuers as a
result of this, even though it wasn’t their issuer that made the
mistake. Who knows, some of them may even change to ANZ.

http://www.finextra.com/fullstory.asp?id=15332
http://www.abc.net.au/news/newsitems/200605/s1642175.htm

===============
5. Newsletter information

This is a monthly newsletter on risk management in financial
services, operational risk and user-developed software from Louise
Pryor (http://www.louisepryor.com). Copyright (c) Louise Pryor
2006. All rights reserved. You may distribute it in whole or in
part as long as this notice is included.

To subscribe, email news-subscribe AT louisepryor.com. To
unsubscribe, email news-unsubscribe AT louisepryor.com. Send all
comments, feedback and other queries to news-admin AT
louisepryor.com. (Change ” AT ” to “@”). All comments will be
considered as publishable unless you state otherwise. The
newsletter is archived at http://www.louisepryor.com/newsArchive.do.

News update 2006-04: April 2006
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe AT louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe AT
louisepryor.com. (Change ” AT ” to “@”). Newsletter archived at
http://www.louisepryor.com/newsArchive.do.

In this issue:
1. Oops!
2. Documentation
3. Is that what you meant to read?
4. A horseshoe nail
5. Newsletter information

===============
1. Oops!

The emails have been flooding in… Did you really mean… Shurely
shome mishtake…

Well, yes, it was indeed a mistake, and some people noticed (half a
dozen emails, not quite a flood I admit). This is the second
newsletter that most of you have received from me this week; I am
sorry for clogging up your mailboxes unnecessarily. The first one,
a repeat of the March issue, wasn’t meant to happen. My processes
failed and have now been (I hope) fixed.

So what actually went wrong, and why? I run the mailing list using
a set of filters and templates in the email program I use, The Bat!
(the exclamation mark is part of the name). Some things, like new
subscribers and unsubscribers, are handled more or less
automatically; I don’t have to write or edit the outgoing email
message acknowledging receipt of the request at all. When
I send an actual newsletter out, there is a slightly complicated
incantation that has to go in the Bcc: field. I can never remember
exactly what the incantation is, so had set things up so that any
new message automatically contained the incantation. I then removed
it when writing a message that wasn’t an actual newsletter issue.

When somebody asked for a repeat sending of the March newsletter
yesterday, I wrote a new message, checked that I’d removed the
incantation from the Bcc: field, and fired the message off. It was
unfortunate that I didn’t double check, as evidently the check
failed.

My original reasoning had been that there would be very few
messages other than newsletter issues. This has nearly been borne
out in practice, though there are more one-off messages than I had
expected. The assumption that the reduced hassle for the newsletter
issues would outweigh the risk of sending an unwanted message out
to all recipients has become invalid as the number of people
receiving the newsletter has increased. So a couple of slightly
dodgy assumptions have gradually morphed into a couple of
definitely unsafe ones, without my processes changing accordingly.

I have now changed the default, so that I have to add the
incantation in by hand when it is needed. The risk of having to
resend an issue because it failed to reach the recipients is
clearly a better one than that of sending unwanted messages out to
all and sundry. Risk management in action, though not as effective
as it should be!

===============
2. Documentation

It is a truth universally acknowledged, that software documentation
is a Good Thing, and spreadsheets are no exception. The FSA, in a
recent newsletter, described what they had seen in the way of good
practice for financial modelling systems: “Acceptable standards of
documentation were established, agreed by the firm, and themselves
documented.” They went on to say “The standards of control and
documentation applicable to systems developments applied equally to
spreadsheets.”

But what is documentation for? It seems to be more or less assumed
that all documentation is worth while, and the more documentation
the better. However, given that most financial models and
spreadsheets are developed with limited resources, and writing
documentation takes time, it’s important to consider what forms of
documentation are most useful and productive. In order to do this
we must think about what we are trying to achieve through the
production of documentation.

Documentation can do four things: specify, record, explain, and
give instructions. These four types of documentation are of more or
less use to different types of user. Furthermore, different forms
of documentation (separate documents, as part of the user
interface, etc) are suited to convey different types of information
to the various types of user. I’ve put together a brief summary of
the options, which is available either as a single pdf document or
as a series of notes on my web site.

http://www.louisepryor.com/papers/documentation.pdf
http://www.louisepryor.com/showTheme.do?theme=17

If you’d like to know more about how I can help you with good
documentation practices, just let me know!

===============
3. Is that what you meant to read?

In previous issues I’ve talked about the problems of hidden data:
how you can inadvertently include information in documents that
isn’t intended to be there. There’s are other sides to the problem,
though: sometimes the reader sees things that they don’t want to,
or don’t see what they should.

For example, if you select some text in your browser, and paste it
in to another document, you expect to see the same text in the new
document as the text that you selected in your browser. Some web
pages have text in them that isn’t always displayed. There are
various reasons for this: for example, it may be displayed only in
some browsers (text-only browsers, or if javascript is disabled,
for instance). Usually, though, this text is pasted in to your new
document whether or not it is visible in the browser you are
using. This can be disconcerting, and could be worse than that; if
there is only a small difference between what you expect and what
you get you might not notice it, even if the sense is very
different.

In some circumstances a single digit can make all the difference. A
recent article in the New York Times describes an incident in which
one partner erased the digit “1” in a Word document, giving another
partner a 5% share in a software firm that had just been sold,
rather than the 15% which was rightfully his. The article goes on
to discuss how computer forensics experts can detect that sort of
tampering and find out when it was done and by whom. It strikes me
as careless beyond belief to rely on a document in electronic form
for that sort of agreement: personally, I would want a signed hard
copy. The huge advantage of electronic documents for some purposes
is that they are so easy to change and revise; no more retyping
page after page for a single minor change. That’s also a big
disadvantage for other purposes, though. It’s a risk that is pretty
easy to foresee, and also one that should be easy to manage; don’t
rely on electronic documents to remain unchanged.

http://catless.ncl.ac.uk/Risks/24.24.html#subj9.1
http://makeashorterlink.com/?F1F85250D

===============
4. A horseshoe nail

Well, not quite a horseshoe nail, and it wasn’t a kingdom that was
lost, but small errors can have major consequences. The true value
(for taxation purposes) of a house in Valparaiso, Indiana, was
$121,900. Somehow some user of the County’s computer system managed
to accidentally change the value of the house to $400 million. The
error meant that the house’s tax bill rose to $8 million from
$1,500, thus radically changing the budget amounts of 18 government
taxing units.

Some interesting points arise. First, how on earth could an outside
user change the taxable value of a house? The official theory is
that “the user probably tried to access a real estate record
display by pressing R-E-D, but accidentally typed R-E-R, which
brought up an assessment program written in 1995. The program is no
longer in use, and technology officials did not know it could be
accessed.” That’s scary. Good design of the interface would check
for valid inputs; when the old program had been taken out of use,
the validation should have been changed. But far safer, when a
program is taken out of use, is to actually move it, so that any
links to it no longer work. Relying on changing or removing every
link is asking for trouble.

Second, how come nobody noticed? “The city of Valparaiso and the
Valparaiso Community School Corp. were asked to return $2.7
million.” Hadn’t they been surprised when the budget came in at a
different level from the one they were expecting? Or is $2.7
million a very small proportion of the total, in which case it
might be insignificant anyway, but this seems unlikely. Surely a
few reasonableness checks, or a simple analysis of changes, should
have rung some alarm bells somewhere.

Third, the county treasurer said his office “spotted the $400
million error after it caused an improper billing, but apparently
it wasn’t corrected elsewhere.” Sounds like a major communication
breakdown. It seems odd that an error can propagate through to 18
government taxing units, while a correction can’t.

http://www.wjxx.com/news/strange/news-article.aspx?storyid=51489

Database Error Causes Unbalanced Budget

There seems to be a general lack of sanity checks in all sorts of
systems. We hear of a publican in West Sussex who got a £600,000
telephone bill. Apparently a member of BT’s staff had “filled in
the wrong details in the wrong box”. The correct amount was £92,
which was exactly in line with the bills the publican normally
got. However, this is as nothing compared to the bill for 806
trillion Ringgit (about £126 trillion) received by a meat importer
in Malaysia. A few days later Telekom Malaysia said “It was a typo,
and it was not our mistake”–apparently it was all the fault of a
debt collection agency. Now, I get lost in the billion and trillion
range, but a quick search shows that a trillion has either 12 or 18
zeroes, depending. Why would a billing system even be able to issue
a bill for that amount of money?

http://www.theregister.co.uk/2006/04/10/bt_bill/
http://uniquoad.notlong.com

It’s not just billing systems that should have data validation and
overall sanity checks. Any financial model or spreadsheet needs
them too. It’s possible to automate data validation, of course, and
some sanity checks, but it’s impossible to overestimate the utility
of a thoroughly cynical user. Instead of thinking “well, I’m pretty
sure the spreadsheet is correct so the answer must be right” you
should always be alert for anything that seems unusual, odd, or
even just unlikely.

If you’d like to find out more about adding data validation or
sanity checking into your spreadsheets or models, just get in
touch.

===============
5. Newsletter information

This newsletter is issued approximately monthly by Louise Pryor
(http://www.louisepryor.com). Copyright (c) Louise Pryor 2006. All
rights reserved. You may distribute it in whole or in part as long
as this notice is included. To subscribe, email news-subscribe AT
louisepryor.com. To unsubscribe, email news-unsubscribe AT
louisepryor.com. All comments, feedback and other queries to
news-admin AT louisepryor.com. (Change ” AT ” to “@”). Archives at
http://www.louisepryor.com/newsArchive.do.