We have a home server which handles our email on our domain name xq.se.
Say you want to give John Doe your email address. You give him John.Doe@xq.se or rh2325@xq.se and then set up sendmail to forward that name to your real user name at home. Even posting to usenet and webpages seems to be safe with a real but disposable email address.
Very occasionally, when you get spam, just disable the address and send a polite email with your telephone number to the culprit. We have never had a spam problem. Why doesn't everyone do this?
Here is a paper which outlines the issues and presents a summary of error rates in the 30 most economically significant spreadsheets we audited last year.
This is not bad journalism. It is a serious article about a serious problem. Take people who have never written a program and have never heard of program-design-101, give them a huge collection of poorly documented functions and tell them construct a large complex program to calculate a number. Just how much would you trust that number? It is not hard to imagine what the resulting spreadsheet looks like. Now suppose that number is, say, the value of a mine, or road, or company. If your number is too low, you miss a great opportunity; if your number is too high, you buy the asset and subsequently lose a lot of money. In either case, the loss is serious money- hundreds of millions or more.
I have spent the last two and a half years auditing spreadsheets for (1) complex financial transactions and (2) models for large public infrastructure projects. I work with a dozen other rocket scientists and actuarial types who specialise in this. My experience is consistent with "some professor from Hawaii", namely Ray Panko who is the world expert in the field. Almost every worksheet of every model I have audited, has been riddled with potential and actual errors- and these spreadsheets are written by professionals and have been already reviewed internally. Auditors like KPMG and PWC are interested in whether an error is "material", i.e. big enough to effect the client's ultimate decision on whether to proceed at a given price. The sample size of 54 is large enough to give overwhelming evidence of the large number of errors, and of the proportion of such errors which are "material".
All software has bugs when you write it. Reviewing your code, peer review, formal testing, code reviews help you reduce that. Even with this, how much released software is genuinely free of errors? I think perhaps TeX is. With spreadsheets, it is hard to write clearly and simply, it is hard to review, it is hard to test and you have no comments. There are going to be mistakes, and lots of them. If you are not seeing them, it is only because you are not looking. To make a spreadsheet (or any software) without errors you need to approach the problem like NASA. This, of course, requires a budget like NASA or a horde of open source zealots, and so PHBs and accountants need to decide when the cost of detection balances the risk of error.
Slashdot Mirror
We have a home server which handles our email on our domain name xq.se.
Say you want to give John Doe your email address. You give him John.Doe@xq.se or rh2325@xq.se and then set up sendmail to forward that name to your real user name at home. Even posting to usenet and webpages seems to be safe with a real but disposable email address.
Very occasionally, when you get spam, just disable the address and send a polite email with your telephone number to the culprit. We have never had a spam problem. Why doesn't everyone do this?
Here is a paper which outlines the issues and presents a summary of error rates in the 30 most economically significant spreadsheets we audited last year.
This is not bad journalism. It is a serious article about a serious problem. Take people who have never written a program and have never heard of program-design-101, give them a huge collection of poorly documented functions and tell them construct a large complex program to calculate a number. Just how much would you trust that number? It is not hard to imagine what the resulting spreadsheet looks like. Now suppose that number is, say, the value of a mine, or road, or company. If your number is too low, you miss a great opportunity; if your number is too high, you buy the asset and subsequently lose a lot of money. In either case, the loss is serious money- hundreds of millions or more.
I have spent the last two and a half years auditing spreadsheets for (1) complex financial transactions and (2) models for large public infrastructure projects. I work with a dozen other rocket scientists and actuarial types who specialise in this. My experience is consistent with "some professor from Hawaii", namely Ray Panko who is the world expert in the field. Almost every worksheet of every model I have audited, has been riddled with potential and actual errors- and these spreadsheets are written by professionals and have been already reviewed internally. Auditors like KPMG and PWC are interested in whether an error is "material", i.e. big enough to effect the client's ultimate decision on whether to proceed at a given price. The sample size of 54 is large enough to give overwhelming evidence of the large number of errors, and of the proportion of such errors which are "material".
All software has bugs when you write it. Reviewing your code, peer review, formal testing, code reviews help you reduce that. Even with this, how much released software is genuinely free of errors? I think perhaps TeX is. With spreadsheets, it is hard to write clearly and simply, it is hard to review, it is hard to test and you have no comments. There are going to be mistakes, and lots of them. If you are not seeing them, it is only because you are not looking. To make a spreadsheet (or any software) without errors you need to approach the problem like NASA. This, of course, requires a budget like NASA or a horde of open source zealots, and so PHBs and accountants need to decide when the cost of detection balances the risk of error.
john@xq.se