Tuesday, 12 May 2009

The Philosophy of Mistakes: How Software Makes It Worse

In the previous post, I advanced the rule that mistakes only exist in the release version. If it's work-in-progress, there are no mistakes, though you may be irritating yourself with your slow progress, frequent re-writes and reference to the manuals. The cure for this is more practice, fewer late nights, less booze, more exercise, reading more technical manuals and going on more courses.

Back in the day no-one looked at the work-in-progress because it was a hand-written mess, needing the skills of the good typist to be made a “release” version. Lawyers had “travelling drafts” - literally a document that went back and forth between the two sides' offices with all the deletions and additions on it. Everyone knew the “travelling draft” was not the release version: it was hand-written and only the insiders could be bothered to read the handwriting.

Software changes all that. When the document exists only in the computer, the distinction between work-in-progress and release version blurs to disappearing. At any given time you can print your spreadsheet, word-processing document, presentation, flowchart, floor plan or whatever. Printed out, it looks like a final version. Worse, you can email it. There's nothing to say “this is not finished yet, so don't bitch and moan about stuff that ain't done yet”. Like it or not, it's going to be treated as the release version – especially when it goes to your manager or someone outside the team. That's just how people treat software documents.

When you had to get the handwritten document typed up, you had a deadline: leave it later and the typing pool would close or you would miss getting the memo out on time. You had to stop revising, adding and futzing and get the thing into the typists.

Software changes all that as well. Because printing the thing takes a moment, you (and more dangerously, your manager) can add, twiddle and futz right up to any sensible idea of a deadline. Running that query will only take a couple of minutes, as will knocking up a pivot table and working up some graphs. And can you show the percentages as well as the values? By region? Oh, didn't I mention I wanted it by region? Is that a problem? After all, at any given time, whatever you have can be printed and is faultless – right? Well, we just discussed that. So you never get a chance to check the damn thing through because the boss is adding, twiddling and futzing to her cold heart's content. There are no deadlines with software. That's just how people treat software documents. No deadlines means no time for proof-reading. Anyway, you do that on the screen, don't you?

It turns out that a computer screen is a lousy place to do serious proof-reading and fact-checking. It just is. The research says we do not treat content on the screen as seriously as we treat it when it's on paper. There is no substitute for paper copy when checking. Strike three for software.

By making it easy to produce huge reports, software provides more opportunities to make mistakes: nobody produced thirty page reports with sixty graphs and tables back in the days before spreadsheets. Nobody would have dreamed of asking for tweaks, revisions and additions to it if they had – but now they do. If you're dealing with very large workbooks with lots of interlocking sheets and large amounts of data and calculations, it will be several iterations before you get all the bugs (the polite term for what are going to be called “mistakes, oversights, omissions, errors and embarrassments” when your manager wants to be rude) out of it.

Which means that if you're doing anything at all complicated, even the release version will have mistakes, oversights and omissions. And it's going to go to a managerial type. Who is going to want to use it to advance their career. So if there's a glitch, you threatened her career, and she's going to threaten you. Dealing with that is the subject of the next post.

No comments:

Post a Comment