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.
...John C. Dvorak were no longer paid to write lame articles?
It is not immoral to create the human species - with or without ceremony, Samuel Clemens.
Why use MUL/DIV --When you have shifts?
Well, shifts and adds. For multiply.
Shift, subtract, jle for divide. :-)
Also, remember that when multiplying 8 bit numbers with 8 bit registers results in a 16 bit result. Its not as easy.
I wrote a whole 32 bit math package for the Z80 "back in the day."
The only way to get rid of Dvorak is to deny him him the clicks. Don't follow the link.
"The ferrets, they're every where I tell you!"
I think spreadsheets evolved almost zero in the last 30 years. Word processing got fonts, colors... Excel is just VisiCalc with buttons.
Wrong. In the last 30 years, they've added everything from statistical functions, to greater programmability to data mining functions. Integration with SQL databases. Desktop publishing features.
And not to mention the most important advance in spreadsheets in 30 years.
Yep, that's right. Clippy!
*ducking*
My blog
Oh my goodness, did they really write it in assembler? I always imagined they already used high-level languages at that time.
And nevertheless, the non-availability of multiplication or division is honestly the smallest problem when programming the 6502 in assembler. Using a decent macro assembler it does not take a lot of effort to implement these two instructions. What i personally collided more with where the awkward addressing techniques of the 6502, and, of course, the quite um... limited stack, and of course, having only 3 registers sucked. I liked the Z80 much more form a low-level viewpoint. But in never though about the absence of multiplication instructions as a bad thing, just a little training....
6502 doesn't have jle. It has bcs (branch carry set/greater or equal) and bcc (branch carry clear/less than).
Do you even lift?
These aren't the 'roids you're looking for.
...Dvorak blames for elevating once lowly bean counters to the executive suite and enabling them to make some truly horrible decisions. even if you believe that VisiCalc was the root-of-all-evil, as Dvorak claims...
That which infuriates me the most about the tech sector is corporate executives building wealth upon the backs of laboring engineers. I have yet to receive an explanation as to why some VP somewhere gets to make ten times as much myself. When the company is not making record profits, it is an engineering problem. When we are raking in the dough, it is an executive success. No one ever looks to see how difficult the problem is because, they cannot fathom the problem being solved. My first day at orientation, you could tell the engineers from the financial analysts. We were in Dockers and collars and they were in three piece suits. Where did we go so wrong that support staff are the ones elevated to executive positions? Why is balancing a checkbook a more executive skill than writing the tool that tool used to balance the checkbook?!?
This only thing that disgusts me more is sharing a sentiment with Dvorak.
The cancel button is your friend. Do not hesitate to use it.
Then we'd go back to making decisions based on gut instinct, rather than what we do now: have beancounters revise their assumptions until the spreadsheet confirms our gut instinct.
If you were blocking sigs, you wouldn't have to read this.
It would be necessary for good journalists to create him?
(Sorry, Voltaire)
My blog
Spreadsheets aren't like guns, they're like methamphetamine.
It starts out innocently enough - a couple sheets here or there - maybe a long weekend working out a household budget. It's all good fun. By the time you realize a problem, though, you're hitting the 65k row limit. You're writing VBA and macros, you're embedding external data sources - and haven't backed up your work for days. It drives you insane and causes brain damage.
Just say no to spreadsheets.
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).
Oolite: Elite-like game. For Mac, Linux and Windows
The Macintosh uses an experimental pointing device called a 'mouse'. There is no evidence that people want to use these things. I dont want one of these new fangled devices. - Dvorak.
John C. Dvorak is the Ellsworth Toohey of the technology world.
"Its easier to blame the messenger, didn't you get the memo?"
Actually, I do blame Messenger for some problems.
"As God is my witness, I thought turkeys could fly." A. Carlson
People would stop combining it with godawful macros in an attempt to cobble together a slow and inefficient relational database with no sensible query or reporting tools and use a real RDBM instead.
How many people can read hex if only you and dead people can read hex?
The spreadsheet was never invented????
Millions of secretaries -- I mean Admin Assistants -- would have to type department phone lists with word processors.
I am not a crackpot.
And not to mention the most important advance in spreadsheets in 30 years.
Graphing. CEOs can't understand numbers, they make their brains run out their ears. Having the spreadsheet program produce charts and graphs for you is the single most important advancement in accounting since language.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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!
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!
I am not a crackpot.
It looks like you are trying to make a standard Slashdot joke at Clippy's expense.
Would you like help?
Forgive me for saying this, but you went "wrong" with your career choice in college. The reason why "support" staff are elevated above you and your fellow engineers (I'm assuming you're an engineer) is that they're administrative support staff, i.e. they are actually trained to run a business (or aspects of the business) and they'll be promoted within the administration of the company; whereas engineers are part of the production team, which means that engineers will probably rise only as far as project or department head. Executives build wealth on the "backs of laboring engineers" (and sales clerks, machinists, programmers, etc) because you're commodities.
I can understand your frustration, but the fact is that in any organization--large, medium, small, corporate, military, religious, political, whatever--there will be only a very few who are able to run the whole thing, and all things being equal, the qualified ones will rise to the top, provided that they're also politically savvy. An unfortunate fact of life is that there also exist within any organization the ass-kissers, toadies, and fast-talking con artists who scheme their way to positions well above their level of competence. Such glaring injustices will rankle obviously, but regrettably the vast majority of people within an organization really don't have a clue how the whole thing works. Forgive me again for saying this, but your post only reinforces this notion; you really don't know what's going on from an administrative standpoint, and I get the strong sense that you are either totally naive about, or disgusted by, organizational intrigue and politics. Good for you, if that's the case. You probably won't get a seat on the corporate jet, but you get to keep your soul.
And I'm certainly not presuming to suggest that engineers cannot run a company; my eldest brother was an engineer who worked at his chosen profession for only about a year after graduating, then went into the financial services industry and took to it like a duck to water. He is now the owner of a successful mutual fund company.
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?"
Some of you already have those cute little shirts on that say disco sucks, right? That's not all that sucks.-Frank Zappa
This is funny.
But it cuts close to the truth.
Spreadsheet planning wasn't the novelty.
The novelty was that plans could be updated instantaneously - without employing hundreds of clerics and dozens of machines to make it happen.
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.
I have worked in a lot of IT positions, and every company I have worked for has always done all of their "real" decision-making on hacked-together spreadsheets. The truth is that the spreadsheet was one of the first "business analysis" tools that was intuitive enough for an end-user to really do power-user things.
That said, Excel and Access "applications" that glue organizations together are the bane of IT's existence. Despite what the sales guys say, all of the company's numbers come out of SAP, Oracle Financials, etc. and into one of these programs to do any useful work with them. I know I'm working on making Office 2007 available to those who want it, and getting some of these Excel and Access 97-era macros carried forward can be...challenging. Access is another horror story -- once a database hits 2 GB in size, file corruption is extremely likely, especially if multiple users are hitting the same database over a network.
If you ever get sick of software development or sysadmin work, and like pain, I guarantee there will be work available for anyone willing to wade through a million lines of VB spaghetti code written by an MBA who took an Excel class in 1996.
Graphing. CEOs can't understand numbers, they make their brains run out their ears.
Bleh. We are spatial, visual creatures by nature, graphs make complex and even simple representations of data much easier for everyone. Dunno, where exactly this whole mantra of it just being for stupid bosses came from when graphing functions were created for mathematicians.
--- I do not moderate.
...John C. Dvorak were no longer paid to write lame articles?
What if Slashdot readers didn't submit them? And what if the editors didn't post them? Then, then I wouldn't be compelled to bitch about them here. I could pretend that meat puppet didn't even exist.
Kwisatz Haderach
Sell the spice to CHOAM
This Mahdi took Shaddam's Throne
Graphing. CEOs can't understand numbers, they make their brains run out their ears.
Bleh. We are spatial, visual creatures by nature, graphs make complex and even simple representations of data much easier for everyone. Dunno, where exactly this whole mantra of it just being for stupid bosses came from when graphing functions were created for mathematicians.
It's a very ancient meme. The Ancient Greeks and Romans had stock characters of the scheming slave manipulating their foolish masters. I suppose in many ways the readers of slashdot are the galley slaves of the modern world. Joking takes people's minds off the fact that being on call is the modern equivalent of being chained to an oar.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
The problem is a phenomenon I call the "competence delta function".
A tool can make many things simple, but sooner or later you run into diminishing returns. As returns diminish, you eventually find yourself at a point where the next thing you want to do takes a step up in competence from what you have right now.
Imagine that you plot effort (on the y axis) and reward (on the x axis). If you are looking for a certain level of reward, you can read how much effort it takes off the X axis. Things like a command line interfaces have a big up front investment to learn, represented by a step function at 0 reward. However the power of command line interfaces (at least good ones), is that the benefits and effort needed thereafter are reasonably proportional over a very large range of tasks.
GUIs, on the other hand, have a low initial step, but eventually you want to do something that has to be expressed conceptually, and there you've got to eat that command line step function and then some. A sysadmin with strong shell scripting and Perl abilities will be able to achieve more than a sysadmin who can only work a GUI.
So the question for an "easy" tool is this: where does the delta function come? Really easy to use tools can be a trap if you don't see this coming. A word processor is highly useful, but at some point you may ask it to do something that would be better done in LaTex.
Spreadsheets are very easy, very useful things. Two dimensional organization of facts may be uniquely useful, giving more flexibility than one dimensional organization, but having none of the capacity for things to hide behind others that three dimensions gives. In fact, the word "plan" comes from the same root as the word "plane".
There are limitations on what spreadsheets can do of course (aside from things like: they are not databases). But I think most people run to the end of their practical, factual, mathematical or business knowledge first. For example, I can say, "prepare a budget for next year," and give you a bunch of spreadsheet templates. If you don't know what you are doing, you'll produce a really bad budget, but it will look great, just as good as a good budget in fact. The reason is, "produce a budget presentation that looks great" is on the left hand side of the spreadsheet delta, but "produce a budget that is financially sound" is well beyond what a spreadsheet application can make easy for you.
I think the same thing goes for the other bete noire of thinking managers everywhere: the PowerPoint presentation.
It's not that PowerPoint isn't a wonderful tool. It's just that it is not a replacement for communication skills. Sometime watch An Inconvenient Truth. You might disagree with Al Gore, but he worked for years on that Keynote presentation until he could really communicate with it. You could take the same presentation, and unless you were an unusually gifted commnicator, you would not achieve anything near an Oscar caliber performance.
As much as PowerPoint is not a replacement for communication skills, it is even less a replacement for critical thinking skills. During the dot com boom, I remember reading how the phrase "send me the stack" was gaining popularity in business circles, "the stack" meaning the PowerPoint slides. Some VCs were so hot to get in on the gold rush the were making investment decisions based on PowerPoint presentations rather than business plans.
A tool that makes certain things easy is always a good thing in itself. The danger is in the illusion that by relying upon it, everything will be easier. Software tools are particularly insidious, because they have the ability to make incompetent efforts look really good.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Hail Clippy, Our Dark Lord!
Hello! I noticed you are using Excel. Do you want to:
o Create a spreadsheet your admins have to fill in for some fire drill information gathering
o Create a CSV formatted file containing all of the employees to be laid off
o Create some graphs with completely meaningless data points
o Use this program as if it was a real database and not a glorified ledger book
It's amusing that you don't know how wrong you are.
One of the very first uses of visual representations of data was by Florence Nightingale to Queen Victoria, a chart showing the relative causes of British military deaths in the Crimean war. The whole reason for the chart being that yes, Nightingale thought Queen Victoria's eyes would glaze over at a table of numbers and she wouldn't be able to comprehend it.
Graphs of functions may have been created for mathematicians. Charts of data were invented for people whose brains ran out their ears at the sight of numbers.