30th Anniversary of the (No Good) Spreadsheet

theodp writes "PC Magazine's John C. Dvorak offers his curmudgeonly take on the 30th anniversary of the spreadsheet, which Dvorak blames for elevating once lowly bean counters to the executive suite and enabling them to make some truly horrible decisions. But even if you believe that VisiCalc was the root-of-all-evil, as Dvorak claims, your geek side still has to admire it for the programming tour-de-force that it was, implemented in 32KB memory using the look-Ma-no-multiply-or-divide instruction set of the 1MHz 8-bit 6502 processor that powered the Apple II." On the brighter side, one of my favorite things about Visicalc is the widely repeated story that it was snuck into businesses on Apple machines bought under the guise of word processors, but covertly used for accounting instead.

Comments

Re:Why use MUL/DIV

[Alioth]

You can do floating point in software, it was done all the time in the 8 bit days, in fact it was done all the time right the way into the 486 days (the 486sx, IIRC, lacked an FPU). It's just not all that fast. But for the size of spreadsheet you could make on a 32K RAM system, the speed of the floating point calculator probably wasn't much of a factor. It wouldn't surprise me if the spreadsheet authors used the BASIC ROM's floating point routine, if it has one (I have no experience with the 8 bit Apple machines. The 8 bit stuff I do play with, like the Sinclair Spectrum and BBC Micro, have floating point calculator routines you can call).

Tooting my own horn...

[SpinyNorman]

Speaking of 6502 programming feats, back in 1982 I worked for Acorn computers in the UK, writing software for the 2MHz 6502 based BBC microcomputer, which incidently we also used as our development machines. The BBC micro had 16K of ROM for the built-in BASIC interpreter and low level "OS", another 16K of address space into which you could map any one (at a time) of the other 16K software ROMs in that machine, and 16K or 32K of RAM depending on the model. Much software was sold on ROM - there were four sockets built-in or you could get expansion boards to allow more - but only one at a time could be selected since there was only 16K of address space for these.

One project I did at Acorn (with another guy) was to implement a Pascal development system for the BBC micro that we crammed into two of these add-in 16K ROMs. This was no cut down version - is was a full-blown ISO certified version of Pascal, the first ever implementation for a Microcomputer to implement the standard and achieve ISO certification (ISO Pascal is different from P-system Pascal which had preceded it).

So, what we fitted into 32K was:

- An ISO Pascal compiler, which compiled programs down to a P-code like stack-based virtual instruction set
- A virtual machine/interpreter for the instruction set
- A 6502 machine code relocator
- The complete Pascal run-time library (full floating point, IO library, heap, etc)
- A full-featured full-screen editor with regex find/replace (with as-you-type syntax parsing and highlighting), block copy/move/delete, etc (in only 4K of code)
- Command line interpreter

Now bear in mind that only 16K of this could actually be in the address space at one time...

The way we managed to squeeze all this in was to have the compiler in one 16K ROM, and the rest in the other. The compiler was written in ISO Pascal and self-compiled to our virtual instruction set. We had to add a few "macro" instructions especially for the compiler in order to get it under the 16K limit. The rest of the software (which I wrote) was all in 6502 assembler. Now consider that to run the compiler you also needed the virtual machine, but that was in a different ROM which could only be mapped into the same address space as the compiler (hence replacing it)... What I did was organize the VM/interpreter into pure code, pure data, and relocatable data (address tables), and implement a 6502 machine code relocator (recognize each instruction type, and know how many byyes they were, and whether they had an address component that needed relocating) which copied the VM out into RAM therefore allowing it to co-reside in the address space with the compiler.

It was a very fun project, not only because of the technical challenge (this was my first job out of college), but also very much because of the memory constraint. I had to use every 6502 trick in the book to eliminate every spare byte to squeeze the assember half of it into it's 16K ROM. Those from this generation may remember things like using XOR A, A as an alternative to LD A, 0 to save a byte, changing tail recursion/calls to jumps (JSR subroutine, RET -> JMP subroutine), taking advantage f known processor flag state to use 2 byte "conditional" (but not if you know the state) branches in place of 3 byte absolute jumps, etc, etc.

Toot toot!

Re:Wow

[Rob the Bold]

Dvorak is an idiot. To use the old adage: "Guns don't kill people. People kill people."

If a bank trusts a spreadsheet based on a bad formula that is provided by the bank itself, is it the spreadsheet's fault? If the CEO chooses that saving 1 cent a year by outsourcing the call center to India, is that the spreadsheet's fault? Please.

There's a lot worser things than people using spreadsheet formulas. For instance, people not using them. Have you ever watched someone with no accounting or technical knowledge enter a bunch of figures in a spreadsheet then turn to the desk calculator to sum them up, turn back to the computer and key in the result? That's almost as bad as how somehow "worser" got into my spell-check dictionary and now I can type it without complaint!

MBA mentality

[klausboop]

I think that Dvorak is putting too much blame on the spreadsheet: it was just an accelerant on an already-burning fire. As Frank Zappa said when asked, "What do you think happened in this country?"

Well, two important things, and each one of them has only three letters: One was LSD...and the other is MBA. When people started taking MBA seriously, that was the beginning of the ruination of the American industrial society. When all decisions are based on an MBA's concept of numerical reality, you're in deep , because the only thing that can be judged as real is that which can be proved by a column of figures. And when all aesthetic decisions are turned over to these kinds of people, who use these criteria to make steering decisions for a company with no regard for people and no regard for what the product really is, and the only thing that matters is maximizing your profit, you have a problem. Because you can't have quality then; you cannot have excellence. Quality's expensive. I think most of these people that come from business schools have the desire to make sure everything is cheesy. That's what happens when you do things that way.

It's the user not the tools

[sjbe]

Dvorak doesn't even know the difference between finance and accounting. Accountants don't really spend a lot of time with spreadsheets. I know because I am a certified accountant myself. Spreadsheets are used far more by finance analysts. Accountants track what happened in the past much like a secretary keeps minutes of a meeting. Finance analysts try to predict what will happen in the future and their main tool is the spreadsheet. These are not normally the same person though there obviously is overlap. Anyone who actually knows anything about business understands the difference but apparently Dvorak is not among them.

Dvorak blames for elevating once lowly bean counters to the executive suite and enabling them to make some truly horrible decisions

Right, because no one ever made horrible business decisions before the spreadsheet. Sigh... Used properly, spreadsheets let us make more informed, rational decisions instead of shooting from the hip. Modern finance would literally be impossible without spreadsheets or something very much like them. Ever tried to manage a company's books? Without spreadsheets and accounting software you need an army of workers to track the paperwork and calculate the numbers. Furthermore hand calculating results in errors and lots of them. Sure spreadsheets can be used badly like any other tool. They certainly are no magic cure-all for bad analysis and decision making. But that's the user not the tool.

Dvorak asks in the article:

How often in years pastâ"the pre-spreadsheet era, that isâ"did an accountant take over a company?

Frequently. John D Rockefeller was an accountant before he was a titan of industry. There are countless other examples. Accounting is what allows managers of businesses to understand what is going on. Every business manager is by necessity an accountant to some degree. Without accounting they are no different than an airplane pilot without any instruments. It should surprise no one that the people who understand the cash flows best often rise to positions of control, including the role of CEO. A spreadsheet and other computerized tools simply make the job easier and more productive. Apparently Dvorak thinks we should rely on slide rules and multiplication tables and ledger books instead.

Dvorak further asserts:

Cars are shoddy, consumer goods are junk. Toxic substances are in the food supply. Lead is in toys. Most of what we buy is made cheaply elsewhere.

Further evidence of Dvorak's stupidity.

• Cars are better now than they ever have been by pretty much any objective measure you care to use. They're more reliable, the last longer, they perform better, they're more comfortable, etc. I know a lot of folks like classic cars for their styling and nostalgia but they were worse mechanically in most cases.
• I have no idea what consumer goods he's referring to in particular. There have always been junky consumer goods and quality ones. Yes we have a more disposable approach these days (which isn't a good thing) but that doesn't mean the products are automatically junk. Some are, some are not.
• Toxic substances have always been in the food supply but again we (in the US at least) have safer and more plentiful food today than at any time in history.
• As for making stuff cheaply elsewhere, that has ALWAYS happened and always will. That's comparative advantage at work. The mere fact that something can be produced less expensively in one location than another says nothing automatically about its quality. It can be better or worse but that's due to other factors besides merely production location. Likewise cost varies because of any number of factors besides just quality. Cheaper does not automatically mean worse.