Advent of Computing - Episode 84 - VisiCalc, the Killer App

Episode Date: June 12, 2022

Today we are looking at VisiCalc, the original killer app. Hitting the market in 1979, VisiCalc was the first computer spreadsheet program. Through it's 6 year lifespan it was ported to everything from the Apple II to the IBM PC to the Apple III. It dominated the market and then... it disappeared.   Selected Sources:   https://conservancy.umn.edu/handle/11299/113026 - Oral History with Bricklin and Frankston   http://www.bricklin.com/history/intro.htm - Bricklin's personal website   https://sci-hub.se/10.1109/MAHC.2007.4338439 - The creation and demise of VisiCalc

I've been having a bit of a problem figuring out how to even start an episode like this, so... Congratulations! It's time for the spreadsheet episode of Advent of Computing. I know just what you're thinking. That sounds so... mundane. That sounds very boring. It sounds like this should be called the Thin Tech Back Office Podcast. Well, let me assuage some of those concerns. To do so, I want to talk about what makes a good topic. So let me give you a rough

checklist that I go down when picking out a new episode. A good topic will be some combination of either impactful to the current state of computing or maybe connected to some larger context around computing. It could also be a vehicle to discuss some aspect of computing. Plus, there's some X factor that can instantly make a topic of interest. That's something like a disaster or some folkloric qualities to a story. I'd say that all of my episodes hit on some of these points. Take my series on early Intel processors, for instance. That topic definitely impacts the current state of computing, since nearly all modern computers are somehow based off early Intel processors. It connects up to the larger context of the development of the first

microprocessors, and it's also a great vehicle to talk about how bigger machines were scaled down, and why people, you know, wanted small computers in the first place. But hey, you don't need to go down that list to know that discussing Intel's early history is going to make for a good topic. It's going to be an interesting time. The early history of spreadsheet software, believe it or not, fits all of these criteria to a T. In the current era, spreadsheet software is a mainstay of any office. That's impactful right there. Sure, it might be a bit of a behind-the-scenes kind of impact, but an impact nonetheless. The story of the first spreadsheet also takes us

into the interesting discussion of the importance spreadsheet also takes us into the interesting discussion of the importance of hardware versus software adoption. So, hey, that's a cool vehicle. As for an X-Factor, well, I think I have that one covered too. Traversing the history of VisiCalc, the first computerized spreadsheet will take more than a few twists and turns to go through. computerized spreadsheet will take more than a few twists and turns to go through. It is definitely something that I'd argue has a bit of a folkloric quality all its own. Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 84, VisiCalc, the killer app. VisiCalc was a spreadsheet application, the first of its kind for home computers, and

really the biggest application for its time. Now, that might not sound too exciting at first, but I'm hoping I can change your opinion by the end of this episode. VisiCalc, for the time, was, in fact, groundbreaking software. But more than that, the story of VisiCalc is a wild and intense ride. But before I get into the actual episode, I have two big announcements to make. Well, a medium one and a big one. The first is that I'm currently running a poll over on my Patreon for another bonus episode. That episode's targeted to come out sometime in July. So if you're a patron, then head on over and vote. If you're not, then I guess I should explain how this works.

So occasionally I do bonus episodes as patron-exclusive benefits. It's a kind of simple setup. You go over, there's a post that'll have three episode topics for the bonus episode, and you vote on whatever you want to hear. These episodes are usually 15 to 20 minutes long, and I tend to focus them on things that are either too small for the main feed or maybe a little less serious. They're also sometimes more technical. The second big announcement is I've been invited to be a keynote speaker for the Human 2022 workshop.

This is part of ACM's Hypertext Conference. It's taking place June 28th in Barcelona and online, which is how I'm attending. My talk is called Doug Engelbart, Notch Cards and Early Links. So it's going to be a discussion of my research into Engelbart's edge notch notes and how hypertext can be accomplished without using computerized media. So if you want to stop by and give that a listen, that's taking place on the 28th. It's in the afternoon in Barcelona, so the morning in the States. Workshop-only

registration is 40 euros, and there's discounts for students and ACM members. I'll put a link in the description, and there'll be links all over my social media leading up to this. So there's also some other great speakers. I think it's going to be a fun time. Anyway, on to the episode. Initially, I had penciled in that this episode would cover Windows 1.0, the first release of Microsoft's very, very long-running operating system line. But this quickly turned into one of those hunts for the start of a thread. To talk about Windows 1, you need to talk about a weird operating system called Vizion. That's spelled like the word vision, but there's usually a space or a dash. Now, to talk about Vizion, you need to talk about VisiCalc.

And, as per usual, each of these steps is full of its own intrigue and import. So here's my plan. This month, June by my current math, is going to be Vizzy Month. Maybe Vizzy June? I don't know, I should probably work on a better name. Anyway, here's the basic rundown. This episode, we're going to be talking about Vizzy Calc. It's creation, rise, and fall.

This will include cameos by Doug Engelbart and Ted Nelson for... some reason I don't fully understand. VisiCalc has been called the first real killer app, the first consumer software that drove hardware sales. It's also been called the first home computer program to go through an entire life cycle. That makes for a nice, rounded-out story with some fun conflict and twists. Next episode, we're going to jump back into the middle of the Visi timeline. Initial development of Vizion starts when VisiCorp, the creators of all this Visi software, is at its zenith.

So tentatively, I'm planning to look at some of the non-calc Visi stuff that led up to Vizion, the operating system itself, and then close with the early connection to Windows 1.0. I think that's probably ambitious enough for this month. But hey, that's all going to be next time. In this episode, I'm going to be looking at a few larger questions surrounding VisiCalc. What does it actually mean to be a killer app? How can software have such a big impact? Or has software always been the driver behind hardware? I think there's some fertile ground to examine there. On the more technical side of things, we get to the matter of portability. VisiCalc was initially written for the Apple II. A few years later, it was kicking around on the IBM PC. Those aren't

really compatible systems, so how did VisiCalc make the jump across platforms? The episode will close out with a discussion of how VisiCalc fell short, and how it eventually got replaced. So, let's jump right in. The roots of VisiCalc can be traced back to Harvard Business School. Hey, I did say there were some twists to this. Maybe this shouldn't be that weird, though. We are dealing with a spreadsheet, perhaps the quintessential tool of pencil pushers in cubes everywhere. So I guess a business school might be the right place for us to start. I guess a business school might be the right place for us to start.

The traditional story is that a student by the name of Dan Bricklin was sitting in a lecture at Harvard Business School, probably in a suit and tie. His professor had drawn a table up on the board in order to demonstrate a physical spreadsheet. The prof was going through the motions of filling in one column with values, then filling another column with values calculated via some equation. After a number of rows, the professor looked up and realized that, much to their dismay, there was a mistake in the equation. They had to erase everything and start over. It was at this point that Bricklin thought to himself, gee, wouldn't it be swell if a computer could just do all that for you? And thus, the VisiSeeds of VisiCalc were planted. That's a really fun and nice condensed story, because afterwards, you get to say things like,

See, great ideas can come from anywhere, or you don't need to be a programmer to create the next big thing in software. And while those are definitely true, VisiCalc isn't a good poster child for that. You can probably see this coming. The whole Harvard to VisiCalc story is missing a few steps. To start with, Bricklin was very much a computer person. Bricklin entered the digital world during a transitionary period. I think these are the spicy spots to be in, personally. He enrolled at MIT in the late 60s. This plopped him in this interesting time where large computers were well-established, the ARPANET was just starting to come online,

and microprocessors were just around the corner. Bricklin had initially entered the math program at MIT, but he quickly switched to computers. It turned out he had an aptitude for the field. To quote from an oral history conducted at the Babbage Institute, The first semester, I tried to stay away from computers for a while, except taking one class, 6251, which was a class for teaching you about compilers and computers, etc.

But I remember going into the final, I was number one in the class. So at that point, I decided to get a job in computers. End quote. The job he got was developing software for Multics. That name might not be super recognizable to some. To simplify things, because it's a bit of a long story, Multics was the spiritual predecessor to Unix. Ken Thompson and Dennis Ritchie started developing Unix because they lost access to a machine that could run Multics. They needed to have a way to get that Multics fix.

So not only was Multics influential, but it was also a huge project. So from the start, Bricklin is working with some high-octane stuff. After graduation with a computer science degree, Bricklin was at a bit of an impasse. You see, a contributing factor for his escape from the math department was the fact that he wasn't the best mathematician out there. As he would put it, his low math grades meant that he was unable to get into any graduate program, at least initially. Bricklin ended up doing an industry-to-grad-school shuffle, but in his own way. After MIT, Bricklin got a gig at DEC. He recalled this time in his life in a lot of detail during the oral history that I quoted

earlier. The high points for us come down to two things. He worked on user interfaces, and he would meet clients face-to-face. Specifically, Bricklin specialized in typesetting and text editing software. This is some real more quintessential back-office stuff. The typesetting software seemed to have been internal to DEC, at least Bricklin describes it as working in a really specific setup that makes me think that it wasn't a super commercial product. But the text editor, WPS8, was most certainly an outward-facing program.

This program is primarily interesting to me because it allowed for simple formatting. WPS8 provides users with a ruler that shows where margins would be once the document was printed. The ruler could also be adjusted, so we have something close to a what-you-see-is-what-you-get kind of editor, aka a wissy wig if you want to scrunch all the letters together. As far as public access, Bricklin had the honor of visiting prospective clients to pitch them on DEC software. I know, perhaps not the highlight of the day for some programmers. I know, certainly that wouldn't be the highlight of the day for me. However, we've seen this before on the podcast,

this interesting dual role of programming plus client interaction. It can often lead to a more innovative approach. Bricklin was lucky in that he came face-to-face with what clients actually wanted. He wasn't totally sequestered off in a cubicle somewhere. As he put it himself, quote, I learned all these things about the real world and how, well, if my thing is more efficient, then I can do a better job, end quote. One of the efficient things that he ran into was a bit of an obscure machine called the Harris 2200. Now, this gives us a fun snag in the story pretty early on. The Harris machine that Bricklin cites some of his later design philosophy to is somewhat lost to time. It appears that the 2200 was a standalone typesetting machine used specifically for creating ads in newspapers.

It's a very niche application. Many of the customers Bricklin was dealing with were newspaper companies, so it was easy for him to come into contact with this very specific machinery. Now, the sourcing problem here is that the Harris 2200 is one of those super niche single-purpose devices. I've been able to find scant mentions of it in a fun book called The World of Digital Typesetting by John Sebold. So that should give you an idea of how specific this machine was. This gives about a two-page description and two nice glossy photos of what the thing was. It's only a dash of data, but it's enough to point out some interesting features. First, the Harris may have had a trackball. Bricklin mentions

that the machine used a trackball for pointing at things on the screen. That's probably true. It's just that I'm one of those trust-but-verify kind of guys, you know me. The verification here is a little ambiguous. The world of digital typesetting does mention that the terminal used a movable pointer for some operations. However, every picture of the terminal I've seen includes someone sitting in front of the machine. They're all action shots. The photos all have part of the keyboard obscured, so I can't really tell if there's a trackball there. There are similar machines that used joysticks, light pins, and trackballs, so there was probably a cursor at play. I'm just a little annoyed that I can't see the smoking trackball, as it were.

Anyway, the second thing to note here is that the 2200 is called a markup terminal. At least, Seabold describes it as such. Seabold explains that the 2200 can be used to generate a template. Then data can be crammed into the spots of that template. The template uses some kind of markup that normal operators don't need to know. In other words, there's a separation between data and its final representation. This little detail perked up my ears. As many listeners will know, I kind of have a thing for hypertext. This is especially true when it comes to older systems. This separation between data and representation

is something that's endemic to hypertext. Now, I'm not saying that we're looking at hypertext here. I think it's clear that the Harris 2200 isn't some missing link. Rather, I want to point out the similarity here because it may aid in our understanding. Digital typesetting, the process of actually laying out a printable page on a computer, does sound a little boring, I will admit. It's totally another one of these office activities that folk do while wearing suits and ties and little boxes. That easily drops it into this sort of shadow realm of obscurity where, despite being important, it's easy to overlook, and in a lot of cases, it's hard to find sourcing on. I'd hazard against that since, as you can see here, there is a connection to a much larger context.

since, as you can see here, there is a connection to a much larger context. Hypertext and typesetting share a number of ideas. You just have to take a second glance. This is kind of going to be the theme of the episode, that Office stuff does, in fact, have important stuff going on just beneath the surface. Before I move on, I do need to check one more line item off Bricklin's CV. After a number of years at DEC, Bricklin moved to another, much smaller company called FastFax. This was more of the mixed programming and client-facing work.

The relevant piece here is that FastFax built their own microprocessor-based point-of-sales terminals. Bricklin had also done some work with a few early-deck microcomputers, but those were using chips based off the PDP-11, so it's a slightly different thing. While those are micros, they aren't really in the line of big home-based lineages. Fast Facts was using the Motorola 6800, which does connect up with later chips. was using the Motorola 6800, which does connect up with later chips. But the stint at Fast Facts wouldn't last for long, from Bricklin again. Quote, when I was in college, I remember thinking that I was going to treat myself after a couple of years and go to business school. End quote. You know, he allowed himself to get an MBA as a treat. If you can't tell, I'm a little charmed by how Bricklin puts things.

He had always wanted to start some kind of business, and business school had been part of that dream. This takes us back to where the story started. During a lecture at Harvard Business School, Bricklin was inspired to build a computer spreadsheet program. But this didn't come out of nowhere. To do so, he would draw on his long history working with computers. This program, eventually called VisiCalc, would start off as a demo. Bricklin actually kept notes throughout the process, so his recounting of the story is sometimes down to the day. I'm not going to get quite that detailed, but it is nice to know that we have some is sometimes down to the day. I'm not going to get quite that detailed, but it is nice to know that we have some good sourcing to work with. Bricklin didn't go straight

from idea to project. Instead, he started with a number of prototypes. The first of these prototypes was written in BASIC on one of Harvard's bigger computers. This was in a time-shared environment, accessed over a terminal. Bricklin would get a rough idea of what he wanted to do before he moved over to a more permanent platform, the brand new Apple II. This was going on in the spring of 1978, just about a year after Apple's new machine was becoming available. As soon as Bricklin got his hands on one of these micros, there was no going back. He wanted to court the small side of the market, and it looked like there was finally enough power to make that possible. This is where we reach our second

key player, Bob Frankston. Bricklin actually knew Frankston from way back. They had connected back in their MIT days. They had attended MIT and both worked on the Multics project. Bricklin actually finished up a program that Frankston had been working on at one point. Now, that's not to say that the two had followed the same path in life. Frankston was a computer nerd with an eye for usability, true, but he was drawn to the lower level of things. As he explains in that same oral history, quote, computer, as well as the technology underneath. So there's a whole sort of systems. I can get out a soldering iron if I have to. I can build a timesharing system, but what I never lost was

the ultimate goal was usability, end quote. Now, he kind of buries the lead in that particular part of the interview. This is from the same oral history, but later on, Frankston elaborates further. Quote, I wrote it originally because I wanted to practice writing a compiler, and that took a night. Another night, I put a front end on it, and the third day, I made it a service. The fourth day, it was censored, but it became a good service.

Very popular. End quote. So yeah, the dude wrote a compiler in a night. That's a very impressive level of productivity and something that I don't think many programmers can match. Frankston didn't work for a big iron company, but instead it sounds like he bounced around a number of startups after MIT. Sometime in the course of the 70s, he consulted for a company called ECD. This is another one of those passing mentions that I can't back up since, as Frankston explains, ECD flopped.

But apparently this company was building some complex and expansive MOS 6502-based computer. Frankston was contracted to develop a basic interpreter for the system. Ultimately, the mysterious company never became solvent, and they ended up subsequently dissolving. Despite this failure, the ECD debacle exposed Frankston to the 6502. This would prove to be a crucial bit of background. So, bringing us back to 1978, Bricklin had a rough prototype. Once it looked good enough, he got back in touch with Frankston. You see, Bricklin wanted to create a commercial project, not just a little puddle-y program. His basic prototype wasn't going to cut it in the market. He needed more firepower. Frankston found this spreadsheet idea interesting, so the two decided to collaborate on the project. Now, there is a third partner to

the story. The Bob-Dan team was rounded out with Dan number two. This one, Dan Filstra, at the time was running a software publisher called Personal Software. The company was just two years old at this point. He was also involved with a new computer magazine called Byte. This connection is important. Flystra would be on the admin side of things. But we aren't going to get too terribly far into that side of the story today. So with the cast in place and a plan roughly laid out, we're entering into a stage of somewhat of a fever dream of a development cycle. Frankston's work ethic was, to put it mildly, admirable. The general rundown was to use Bricklin's demo as a way to quickly test out ideas for the final program. As tweaks were being made and worked out on that side, Frankston would re-implement the

software in 6502 assembly language. Eventually, all efforts would become focused on the assembly version of the spreadsheet, so in theory, they'd get the best of both worlds, a rapid testing environment and a polished final product. The apartment that Bricklin was living in happened to have an unused attic at the time. That space was turned into a makeshift office for the as-of-yet unnamed company. Most of the serious programming took place in that attic. Now, there were some circumstances that made this into an interesting process. The target platform was the Apple II.

Specifically, Frankston was using assembly language. At the time, the Apple II didn't have very good support for self-hosted assembly language development. But hey, there's always a way around these kinds of limitations. Frankston ended up programming on a mainframe running Multics back at MIT. This was done remotely from a teletype terminal in the attic office. This was all thanks to a neat little program called a cross-assembler. This is just like a normal assembler. It takes an assembly language and outputs a binary program. Except the finished program is for a platform other than the assembler's host platform. Frankston was working on some big iron machine running Multics, but this program was being assembled to run on the 6502

inside an Apple II. This allowed Frankston to use all the development tools he was comfortable with, while still targeting the smaller Apple II computer. However, this setup had some downsides to it. Frankston and Bricklin didn't work at MIT anymore, so they couldn't just sneak onto a computer. They had to pay for time. Frankston ended up working almost exclusively at night, since that was when computer time was at its cheapest. This led to a bit of a fun programming habit. To quote from Frankston again, one of the big challenges was staying awake while you work at night. One of the things I learned earlier, timesharing, when you did a long compile, you could put your head down on the terminal and fall asleep, and it would ring a bell or something to wake you up when

it was done. So there were all these kinds of techniques, end quote. Hey, sometimes you have to do strange things to get the job done on budget. Another annoyance was getting the final program running on the Apple II itself. The actual bits that made up the program had to be transferred over to the computer. The setup for this, from what I gather, was a little complicated. From his terminal, Frankston would tell Multics to dump the program. Then that data would get redirected over a cable to the Apple II's serial port. So you get this indirect form of data transfer from a mainframe over the phone lines, over a terminal, over another wire, into the micro.

But apparently it worked well enough. We've been talking about the development cycle here, but what about the software? What was the actual program that Bricklin had designed and Frankston had built? The first name chosen was the awkward CalcuLedger, but that was just a placeholder and I don't like it, so I'm going to be sticking with the release name of VisiCalc. There is one other naming thing that I need to point out to save myself some breath. The company that initially develops VisiCalc is named Software Arts, that's synonymous with Frankston and Bricklin inside an attic. Once things progress, that org is renamed VisiCorp. In general, I want to try and stick with the Visi name scheme just for clarity. The interface here will sound familiar if you've used any kind of computer spreadsheet software. VisiCalc, since inception, followed a simple grid layout.

Bricklin had played around with the idea of user-defined labels for rows and columns, but that turned out to be impractical. VisiCalc needed some uniform way to reference cells in the sheet, so custom labels were kind of kicked out early. Bricklin settled on letters for columns and numbers for rows. That way, a cell on the sheet was identified by a letter followed by a number. You get spicy and popular locales like A1 or C12. That grid made up the bulk of the actual screen since, you know, that's where you were putting your data. One of the first major considerations was how to navigate the grid.

This was also where we need to remember that Bricklin wasn't just some business school dude in a suit. He had connections in the world of computing. Both he and Frankston were embedded in the larger computing context. The design of VisiCalc was very much in dialogue with current developments. Once again, from Bricklin. I had seen Engelbart's stuff with the mouse. I worked with Andy Van Damme one summer, and I had seen Press and their type of stuff. So to me, it was all natural progression. I met Alan Kay. I had seen his stuff and I was inspired by Alan's stuff before I went to school. So that type of stuff, to me, it's great. Normal progression in terms of stuff. Remembering the mouse, VisiCalc was

supposed to be done with the mouse. End quote. That's a pretty big trifecta there. Engelbart, of course, was one of the creators of the computer mouse. Andy Van Dam worked with Ted Nelson to implement one of the first hypertech systems. Alan Kay was one of the forces that made Xerox so innovative in this period. At least two of these were working with mice. Van Damme was running a light pen-based outfit around the same time. Add in the Harris 2200, and it's perhaps obvious that Bricklin wanted VisiCalc to use some type of mouse. It just seemed like that would be the way to go. In 1978, though, that wasn't really possible. Apple's first mouse was released in 1983 with the Lisa. An Apple II mouse would come out in 1984.

That's a little late for VisiCalc to take advantage of, at least in the short term. Bricklin would try a number of other options. One of my favorite attempts was the paddle controller. This is a funny little input device. It's essentially a dial that you can twist back and forth. Paddles were famously used in Pong and its many clones for controlling, well, the on-screen paddle. Bricklin tried using paddles to navigate VisiCalc's grid, but it just wasn't the right tool. These aren't very precise input devices, so it was easy to overshoot. Overall, just not the best tool for the job.

He eventually settled on using the Apple II's arrow keys for navigation. And overall, I think that was a really smart decision. You don't need external hardware to use the program. And user experience-wise, this also seems like it was a great choice. The arrow keys are, shocker, I know, on the keyboard. That means you don't have to move your hand off the keyboard to navigate. You can stay comfortably close to your precious keys. It's also just easy to understand. Want to go right? Well, there's a button for that. Right on the keyboard. It's the right arrow button. It even points in the direction you want to go. You can't

get much more simple than that. For 1978, this was probably a better choice than using a mouse. Above the grid, you get these three cryptic lines of text, a message line, a prompt line, and the status line, aka the edit line. The message line is pretty simple. It shows you information about the cell you're currently pointing at on the grid. As you move around, it updates to reflect what you're pointing at. updates to reflect what you're pointing at. If you have some value like 1, then the line just says what cell you're at, so B1 or so, the value of the cell, and then a note if it's a literal value or an equation or something else. Below that is the prompt line. When you issue a VisiCalc command, this line pops up some text to walk you through the command. That's something that I'm going to get into when we actually look at the more complicated part of the program's

design. The third line is the edit line, and this is kind of where a VisiCalc user ends up living. This is where you actually input information. To drop a value into a cell, you highlight the cell you want, and then you start typing. Your input shows up in the status line and then gets moved into that cell when you move the cursor. There is a little weirdness here. If you already have data in a cell, then that data shows up in the message line when your cursor is over that cell instead of the edit line. In my head, at least, it makes more sense to show that information in the edit line. In my head, at least, it makes more sense to show that information in the edit line, but hey, at worst, that's just something you have to remember. The whole three

line thing makes operating VisiCalc a little more complicated than just blitzing data into cells, but it generally works really well. The setup also solves a few programming headaches. well. The setup also solves a few programming headaches. In VisiCalc, each cell starts off as 9 characters wide by 1 character tall. You can edit that size, but that's outside the standard and it applies to every cell in the sheet. So what should the program do if you put 10 characters into a 9 character wide cell? VisiCalc will store that whole value, but only display the first 9 characters. You can see the full value by placing the cursor over the offending cell. It's a simple solution, and it means you don't have to write code to automatically scale your grid or do something else nasty. I also like that you only ever have input in one exact place. That means Frankston

didn't really have to worry much about fancy text inputs. It's not the end of the world to write fancy code that handles keyboard inputs at any location on the screen. It's just kind of prone to error. Once again, like with the above example, you run into scenarios where you might have to move stuff around on screen to accommodate weird inputs, and believe me on this one, users love generating weird inputs. That's basically all of the on-screen user interface. But there is one other noticeable part of VisiCalc's look and feel, so to speak. This is a very loud program. VisiCalc likes to communicate its frustration with weird user inputs via sharp beeps and boops. You get beeped at

whenever you try to backspace too far, or input a bad command, or try to go off the grid, or, well, try to do anything wrong. This is a weird feature, to me at least. I mean, I get the purpose. It's to let the user know that they're making a mistake without cluttering the screen. But it's kind of jarring. I can't imagine it was very welcome in an office, either. Imagine the embarrassment of your fourth or fifth straight beep,

or the frustration of hearing a new coworker constantly beeping away in the corner. Despite some idiosyncrasies, that should sound a lot like modern spreadsheet programs. I think you'll see where this is going pretty soon. So, on to the actually exciting topic. Data entry. And hey, this is an entire episode about accounting technology. So, on to the actually exciting topic. Data entry. And hey, this is an entire episode about accounting technology. So, this is the exciting part.

Now, jokes aside, this is actually where VisiCalc shines, in my opinion. You can enter numbers no problem, just type them in. You can also put text into any cell. You don't have to do anything special, just type them in. You can also put text into any cell. You don't have to do anything special, just type it in. What's cool about this is you can very easily throw in labels and annotations. In a real ledger, you'd probably label each column, maybe add a label next to a total value, maybe a note or two. So a computerized ledger should be able to do the exact same thing. Going to the next level, we have equations. Now, this is another part where

Bricklin and Frankston made a couple smart choices. To add an equation, you type in a plus, and then your equation. That's it. It's really a simple interface. You reference the data in other cells by their column letter and row number. A1, B3, C2, that kind of thing. These equations are written in a very standard algebraic notation. You can just write plus A1 plus 1. No need for special computer lingo outside the cell names and a prefixing plus. This means everything is clear and easy to use. Once again, this is a really simple win. When you finish writing an equation, you hit enter or move the cursor, then the value is calculated and displayed in that cell. You can view and edit the equation via this three-line shuffle up top, but in the grid,

you only see the calculated value. It should go without saying, but you can also use the results of an equation as the inputs to other equations. This is done transparently, you just reference the cell you want. And here we have the total solution to the problem Bricklin saw in his business class. Keeping the value in the grid while hiding the equation away in the top line

is a slick UI trick. It also serves a deeper purpose. If you change a value in your sheet, then that impacts any equations that reference it. No more updating every single cell if you make a mistake. This, for me, is a fun peek-behind-the-mask moment. The trick VisiCalc pulls here is possible thanks to, say it with me now, separation of data and representation. A cell might hold an equation, but on the sheet, it's just a nice number. This is something that Bricklin

was especially familiar with from his work with typesetting. When preparing a document, you use some kind of markup to specify how the document will look. The finished document, what actually goes to print, isn't a bunch of code. It's a nicely formatted paper, maybe a slick ad. The representation doesn't match the underlying data. As I've already hinted at, there is another place where we see this type of separation. Hypertext. I know, roll your eyes all you want, but we've already had some surprise appearances, so I'm just in a certain state of mind. Most hypertext systems differentiate between their internal data and the finalized information displayed to the user. Look no further than Andy Van Dam and Ted Nelson's HES. This system kept data stored as tiny chunks of text,

each chunk with its own unique identifier. Documents were actually lists of these unique identifiers. On the back end, that's really just a pile of numbers, but once displayed, it becomes a full-text document. In Nelson's vision, this chunk-by-chunk approach would allow for centralized editing. Let's say all your papers start with the same header text, something like Welcome to Advent of Computing, you know, to pull an idea out of the ether. You might have, I don't know, 84 files that all start with that. What happens if you need to change that text? four files that all start with that. What happens if you need to change that text? Maybe you just need to add a copyright tag for legal sake. Well, with HES, you would only need to change that line once. Just update to add a subsidiary of IBM to that string, and boom, every reference will get

updated. VisiCalc is doing a very similar thing here. When a number is changed, all equations that reference that cell are updated. That's massively convenient and, ideologically, really similar to some wacky hypertext research. VisiCalc also provides a number of handy functions for your calculating pleasure. These functions let you run sums, averages, trigonometry, basically anything outside normal arithmetic that you could want. Some of these functions, like sum and average, take lists of input. This is notated using a triple dot,

so the first 10 items in the A column would be notated as A1 dot dot dot A10. Functions all start with the at sign, and I think that's mainly to help VisiCalc's parser keep things straight. Overall, once again, it's very nice and simple syntax. The other piece to note here is that VisiCalc provides two ways to select cells. You can type in the location, or you can select using the cursor. The program is smart enough that anytime you can type in a cell's location, it'll also let you move around the cursor and hit enter. As the cursor moves, the edit line automatically updates with its current location. It's just really straightforward. In general,

most of VisiCalc is just that. It's really straightforward. And that wasn't by accident, if you can believe it. Bricklin was insistent that the program be accessible. This is one of the reasons that he took the whole prototype route. The basic version made it easy to tweak and adjust the program and try new things. Bricklin and Frankston would show off VisiCount to anyone that they could get a hold of. Testing was near constant. The goal was to keep the program as simple and usable as possible. As Bricklin puts it, quote, if it wasn't easy to describe, then we would change how it was implemented.

End quote. I think that cuts to what makes this program so good. It was designed to be good through rigorous work and testing. The target audience Bricklin went for was the business person, someone who doesn't necessarily know about computers, but would definitely benefit from an automated spreadsheet. So the Visi team tested their software on those kinds of people. The first devoted users of VisiCalc were actually Bricklin and Frankston themselves. Bricklin would use the then-named CalcuLedger during a school assignment.

Frankston, on the other hand, used VisiCalc to do his taxes. This approach of constant testing, iteration, tweaking, and actual use led to a truly slick program. By mid-1979, the new Wonder spreadsheet was ready to leave the attic. However, it would have a pretty small start. Bricklin has chronicled all of this in fine detail on his personal website, so I'm pulling from there for this section. The first ad for VisiCalc ran in Byte Magazine in May of 1979. It was a tiny ad that simply said, VisiCalc, TM.

How did you ever do without it? From there, Bricklin and Frankston hit the show circuit. The first actual showing of VisiCalc was at the 79 West Coast Computer Fair in San Francisco. Bricklin demoed the program for a select few attendees. Frankston would present on the program at the National Computer Conference that year in New York. But there was a frustrating problem with these early demos. People just weren't excited about PhysiCalc. I think this comes down to the audience that the team was targeting. Non-computer people. PhysiCalc wasn't some new programming language. It wasn't blisteringly fast, sophisticated software. It was a business tool.

It had sophistication in its own right, but it wasn't very flashy. Just describing it was a bit underwhelming to transistor heads. There was a silver lining in this early phase, though. It seems that anyone who used VisiCalc was easily converted over to the cause. it seems that anyone who used VisiCalc was easily converted over to the cause. The first big positive press came from Ben Rosin, at the time an employee of Morgan Stanley Bank. Rosin was another MBA dude with a keen interest in tech. From what I gather, Frankston and Bricklin had been sending out demo discs of early versions of VisiCalc. Rosin became exposed and soon became something of an evangelist for the program.

He wrote an article singing the program's praises titled VisiCalc, Breaking the Personal Computer Software Bottleneck. The article cuts to the root of what made VisiCalc a big deal. As Razin explained, In mainframes and minicomputers, hardware developments have always outpaced those of software. deal. As Rossen explained, quote, This is an angle I've never really thought about before. The Apple II was released to market in June 1977. The machine shipped with BASIC in ROM. Initially, the machine only had a port for connecting a cassette deck, so you could load software off a tape or type in a program in BASIC. During the early days, Apple II users subsisted mainly off homespun software or hobbyist code.

There weren't many big commercial releases for a number of years. Part of this probably comes down to market size. I've seen estimates that state Apple sold under 8,000 computers in 1978. That market isn't exactly spicy early on. Or maybe put a better way, the market for home computing software was way too new. This is the kind of situation where well-timed but mediocre software could do very well. And VisiCalc was far from mediocre. Rosen's glowing endorsement was a sign of things to come. As he saw it, VisiCalc was the future.

For home computers to blow up, there had to be a reason for non-hobbyists to pick up a machine. VisiCalc offered one compelling reason. That reason went on sale in October of 1979. The original release of VisiCalc cost $100, or around $400 when adjusted for inflation. Not the cheapest program in the world, but also not a title that would break the bank. The matter of price here is also kind of tricky to think about. Both Bricklin and Frankston think that they undervalued VisiCalc, but there's a balancing act to do here. To use the program, you needed an Apple II, which cost $1,200 at the time. You also needed a

floppy disk drive, which sold for a slick $600. Add in a printer, and the total package is maybe around $3,000, maybe more. Now, it's hard to make a direct price comparison, since there wasn't really anything like VisiCalc on the market. One quick and dirty comparison is to look at this computer plus VisiCalc package as an entire application. Frankston compares that package to single-purpose word processing machines. If you thought spreadsheet software was mundane and banal, then man, dedicated word processors take that to another level. These were machines built just for editing text documents. The banality of back-office nature makes pulling information on specific models,

well, kind of difficult. The best I can say is that one of these word processing systems tended to cost upwards of $5,000 in the late 1970s. That's not a super good comparison, but it's the closest we can really get. This is the secret sauce that really made VisiCalc a killer app. It was a well-polished program, it showed up at exactly the right time to be impactful, added in the low, low price, and you get a real triple threat. Initially, this only really made a splash alongside the Apple II, but that would quickly change. I've seen a range of estimates, but the best we can say is that in the first six years, VisiCalc sold somewhere between 700,000 and maybe a million

copies. So we can guess that somewhere north of 100,000 copies moved each year. Those are some serious numbers, especially as we've talked about for such a small and new market. Early success changed things considerably for Bricklin and Frankston. The first step was to leave the attic and move into a plush new office. This was still a humble affair to be sure. Their new digs were in a basement, but at least it was in a real commercial building. With some early royalties plus a loan, the company was also able to purchase their very own mini-computer. Now, I've seen a lot of hay made over this purchase. At the time, the duo were still going by the whole Software Arts name. Their company had one product that was still really new to the market. At this point, VisiCalc wasn't even fully packaged as a retail product.

There were some sales going on. There were some early royalty payments. going on, there were some early royalty payments, Software Arts wanted to have a computer so they could make a finalized retail version before sales really kicked off. Bricklin put this purchase in very practical terms. Timesharing was becoming too expensive. It was going to cost more to rent computer time than to actually buy a computer outright. To complete the release version of VisiCalc, the duo developed a set of new development tools. Frankston would write a custom assembly system, while Bricklin wrote an editor. Both of these side projects played to each programmer's strong suit. The VisiCalc that shipped and dominated the market had been developed

using this custom set of tools. If you're keeping track at home, that's at least the third iteration of the program. That brings us to the matter of ports. That is, how did VisiCalc get from the Apple II to other home computers? At the time VisiCalc was developed, there were three major home micros. The Apple II, the Commodore PET, and the Tandy RadioShack TRS-80. The port over to the PET was probably the easiest. Commodore's machine used the same 6502 processor that was tucked inside the Apple II. That meant that both machines could execute the same code. The key differences lie in how each computer handled its hardware. So a port between the two computers

came down to changing how text is displayed, how keyboard input is handled, how files and printers work. No need for a rewrite, just some tweaks. The port to the TRS-80 was a little more involved, since that computer, unlike the other big three, used a Zilog Z80 microprocessor. That's just a different beast. By the time this port was on the table, money had already started to flow in, so VisiCorp had more than two employees. The programmer taking up the task was one Seth Steinberg. What makes this port notable is the restrained approach that Steinberg took. He wasn't going in with some blank slate and trying to reimplement something that acted like VisiCalc. Instead, he parted the code almost instruction for instruction.

From Bricklin again, quote, He basically left the comments in the 6502 code and just wrote Z80 code that did the same type of stuff. We found out sometimes the bugs were actually the same. And when you printed it out, the listing actually listed the comments from one to the other, and you can compare the two. End quote. This is an interesting case of code comments really saving the day. I mean, code comments are usually good practice for adding readability and debuggability, but here they served very functional purpose. I think this also gives us a peek at how professional the overall project was. Doing a straight conversion without adding any special tweaks or flair, that's not easy. Bricklin even points out that he was impressed by Steinberg's professional resolve during the project. Most programmers like to add in their personal touch, but in this case, Steinberg stuck to the script.

The fact that comments were good enough to explain how VisiCalc worked, well, that also gives us a hint at the level of professional conduct here in general. And thus, VisiCalc moved over to another platform. Parting in general would become a big marketing gimmick for the program. The simple fact was that no one had really won in the home computer market, at least not yet. By being everywhere at once, VisiCalc was able to keep on top of things. Come 1981, things would change. This is the year that VisiCalc entered dangerous territory. This is going to be straight from the IBM PC's initial press release.

Quote, VisiCalc is available for applications ranging from financial analysis to budget planning. End quote. Now, I've talked before about how innovative and non-IBM the PC was. This wasn't just a matter of the tech side of things, but more so everything surrounding the technology. Planning, compromise, marketing, and software sourcing all played a huge factor in the PC's success. One thing IBM chose to do was solve what Rosen had called the software bottleneck. IBM contracted with companies to prepare software that would launch at the same time as the IBM PC. Just for fun rundown memory lane, this included advent of computing alums such as Microsoft DOS, an operating system that may have been cheated away from another company. The Source, a strange, soulless Colossal Cave Adventure, which was being sold

despite being a more open source type of title, and VisiCalc, the killer app from 1979. VisiCalc had found itself once again in the exact right time and place to dominate the market. in the exact right time and place to dominate the market. This was the second time in a row that VisiCalc was going to be the killer app on the new platform. On release, no one knew that the PC was going to be the platform of the century. When it took off, VisiCalc came along for the ride. The port to the PC followed VisiCorp's usual MO. They treated this like any new platform, because, as near as they could tell, that was the case. There are actually

some neat tricks that were used during this port. The Zilog Z80 is based off Intel's 8080 processor. based off Intel's 8080 processor. The IBM PC used Intel's 8088 microprocessor, which was designed to have a certain level of backwards compatibility with the 8080. I know, that's kind of a maze of eights, but here's the bottom line. Intel had designed a migration path so older software could be revamped to work with their new chip. An employee at VisiCorp developed a new tool that could convert their Z80 assembly into x86 assembly that was compatible with the new IBM PC. This new assembler was smart enough to mark anything that it couldn't convert, that way programmers could go back and do spot

checks. As a result, this was a relatively painless and not super labor-intensive port. It also sounds like a really professional job. They're developing custom tools to do specific jobs, and they're using what sound like good practices. But therein lies the problem. using what sound like good practices. But therein lies the problem. There's a big difference between the Z80 and the new PC platform. VisiCalc had been developed on 8-bit computers. The PC was a 16-bit machine.

VisiCalc had been designed for the comparatively tiny Apple II. The PC had much more power at its disposal, but the port of VisiCalc was never updated to take advantage of that. It was a faithful port, but that would become a downside. Here I'm drawing on two really fun articles. on two really fun articles. Tracy Licklider's 1989 piece and byte titled 10 Years of Rose and Calm and Burton Grad's The Creation and Demise of VisiCalc, published by IEEE in 2007. I think combining these two articles gives us a really good explanation for why we aren't using VisiCalc in the 21st century. The short answer is that VisiCorp made the wrong choices at the exactly wrong time, and the PC port is emblematic of this problem. Since it was ported more or less directly from an 8-bit program, it had all the limitations that had originally been imposed back in the Apple II days.

Sheets were limited to a grid of 63 by 254 cells. Bricklin had initially wanted to include a built-in help system, but that got scrapped due to space limitations. You could only open one sheet at a time. One more esoteric problem was the matter of how equations were actually recalculated. VisiCalc took a very brute force approach here. It simply scanned the sheet column by column or row by row and re-ran any equations it saw. So yeah, you could have an equation that referenced another equation. That would work just fine.

However, you had to be careful about where those equations were placed. You could, in theory, build up a sort of loop of referential equations such that, on update, propagation didn't work. Intermittent values would be taken, thus ruining your result. Another fun side issue was that VisiCalc's interface was pretty barren. There was a third layer to things that I haven't really gone into so far. Commands. This is how you do things like clearing cells, moving rows and columns, replicating cells, and even splitting the screen into two separate windows. These commands were where a lot of VisiCalc's true power was locked away. They also kind of suck to use. To start a command, you type a slash

followed by a letter. So to replicate rows, you might type slash R. Some commands, like replicate, lead to a series of prompts. It works, but it's not very plush. You have to learn the program or have a cheat sheet. The lack of built-in help makes this all the more annoying. You just gotta deal with single letters in the program saying, what command do you want, followed by a string of 15 or 16 random letters. There was clearly room for the product to grow, but that wouldn't happen with the PC port. Grad explains that VisiCorp was trapped in a spiral of ports.

They had bet on widespread multi-platform adoption, which was a good choice early on. But that meant they had to support all those platforms. Bug fixes had to propagate to all those platforms. To quote, the company was working on VisiCalc 2, eventually called VisiCalc Advanced Version, in parallel with the porting and maintenance. There was even an intermediate version for the Apple III that had some special features. End quote. The company was getting spread thin. A new version of the spreadsheet was in the works,

but that project had to occur while supporting existing versions. I particularly like the note about the Apple III since that's such an obscure flop of a machine. I think it really shows how VisiCorp was targeting, well, everything. While the Apple III version may have had fewer limitations, most platforms were left waiting for an upgrade. This is when Lotus struck.

To be 100% clear, VisiCalc had competition once the PC was on the scene. Microsoft had even tried to break into the market, but VisiCalc had remained the undisputed champion in the sector. I'm only going to cover this part of the story briefly, but I think this will make good setup for next episode. So, here's how VisiCorp finally died. In 1982, Mitch Kapoor left the company. He was a developer who had worked on two major projects,

VisiPlot and VisiTrend. These were ancillary tools used with VisiCalc for generating plots and analyzing data. Sheets from VisiCalc could be exported to a portable format and then fed into these programs. These were tools that were also sold separately from the spreadsheet itself. But Kapor had a vision. Why not bundle all the outlying Visi code together, throw on a fresh coat of paint, and release a supercalculator. His proposal didn't come at an opportune moment. The corporate side of things here sounds like a bit of a tangled web that I can't hope to unravel. From what I understand, there was a restructuring occurring

due to key employees leaving the company. There was also a big project underway. That project was called Vizion, a new next-generation office suite and operating system that was poised to revolutionize home computing. So no one really listened to Kapor. Hence, he left. Kapor started a new company called Lotus, along with another ex-MITer named John Sachs. Funnily enough, the venture was backed by the same Ben Rosen who claimed VisiCalc was going to be the future of computing. I guess the future had shifted a little bit. Their first big hit was Lotus 1-2-3, a package that combined a spreadsheet, database, and plotter. It had everything that VisiCalc lacked, including a slick menu system.

VisiCalc just couldn't change fast enough to compete. But there was one last hope. What about Vizion? Well, dear listener, that's going to be a story for next episode. Alright, that brings us to the end of this episode. This is where we leave VisiCalc, but not where we leave the larger Visi discussion. VisiCalc was an impressive program for the time. It was the result of shrewd planning, smart choices, and some very professional programming. However, there was a fatal flaw.

You could say that VisiCalc suffered from its own success. The emphasis on ports over upgrades would spell doom once a better product came along. That said, VisiCalc ruled the office for around six years. It turned home computers from hobbyist machines to office equipment. It arrived before anything like it existed. Therefore, I think it's fair to call VisiCalc a true killer app. Next time, we're going to be living in those happy middle years where VisiCalc ruled the offices, where it sailed briskly over the cube farm. We will look at how the success of one program would lead to the development of an entire suite. We'll be looking at Vizion and how it inspired Windows 1.0.

See you in two weeks, and until then, I want to thank you for listening to Advent of Computing. If you want to help support the show, there are now a few ways you can do it. If you know someone else who'd be interested in the podcast, then why not take a minute to share it with them? You can also rate and review on Apple Podcasts. And if you want to be a super fan, then you can support the show directly through Advent of Computing merch or signing up as a patron on Patreon. Patrons get early access to episodes, polls for the direction of the show, and bonus content. You can find links to everything on my website, adventofcomputing.com. If you have any comments or suggestions for a future episode,

then shoot me a tweet. I'm at Advent of Comp on Twitter. And as always, have a great rest of your day.