Special Reports
Q&A: Software Pioneer Dan Bricklin
The inventor of the first PC spreadsheet talks about his new book and challenges facing developers.
Dan Bricklin is best known as the creator of VisiCalc, the first computer-based spreadsheet launched in 1979. The program has been widely heralded as the first killer app of the PC computing age, illustrating how a single, compelling application can vault a platform to broader success. Bricklin today is president of Software Garden, a small consulting and software development firm. In May he published his first book, titled "Bricklin on Technology."
We spoke with Bricklin about his book and how developers might apply some of his observations to their jobs.
Why write this book? It's 2009 and big picture tomes about the role of computing and technology have been written before.
I felt that a lot of the stuff I had been writing [in my blog and in articles], people keep on finding it again and again, and finding new meaning in it, or meaning that was always there and still was applicable. So I tried to take those things and put them together. It can be used for people who want to learn quickly, to get an overview of certain ways of thinking about the use of technology and people. One of the reviewers wrote that all product managers should read it.
In the book, you discuss the continuum from procedural to declarative to WYSIWYG development. How is this relevant to developers?
All of the professional-level languages are in the hardest category, as I put it. They are for professionals. They give you the most power. What the development environments do though is take care of some of the tedious manipulation. And they give you better ways of being able to define various data structures and things like that. From a programmer's viewpoint, it is a major step in lowering the complexity in terms of dealing with things -- you can deal with things that are much more complex. As programmers, what we do is we usually go to the level of complexity we can handle. So if our tools let us make things easier, we go up to that same level complexity and can do a lot more than we used to, because of the leverage of the tools.
What I'm most concerned about is what you're building for the user. The user who has other problems to deal with and the program that you're building is a tool that they are using for some other purpose. And that is what I am most concerned about in terms of the user interfaces. A better type of interface is one where you provide a metaphor that shows to the user and presents to the user a data space and a command space in a more natural way with regard to the problem. A spreadsheet is that way, a word processor is that way, a lot of drawing programs are that way. That's the type of general purpose tool that we have come to learn can be really dominant.
But you don't have to build a general purpose tool that can be used for a very wide space of problems. It may be a very transparent tool for a very narrow space that's around the problem space you are trying to solve.
We spoke with you for the first issue of Redmond Developer News back in 2006 At the time, we discussed Microsoft gaining respect for open source and working with it. Can you update us on your impressions on Microsoft's open source adoption today?
I can only give you the impressions I can see in my interactions with different people at Microsoft. Clearly there is a respect among many people in Microsoft for open source and its place in the world. There's also an understanding that there are other models that are often applicable for various applications and for running companies, of which Microsoft uses a lot itself.
Unfortunately there are still parts of Microsoft that are perceived, maybe rightfully so, as at great odds with open source and trying to hurt it in different ways, as opposed to trying to help the movement. Microsoft of course takes advantage of open source in many ways, releasing some of its standards and some of its samples in ways that developers can take advantage of. If you don't produce sample code that others can use, it is very hard for others to build upon that. But Microsoft still has the image and still seems to act in many ways, where it hasn't embraced that part of the world as much as maybe it should, compared to where some of its customers are.
How does open source development differ from traditional approaches
When you develop open source, you often are thinking differently in terms of what the person who will be using your code and next touching your code will be like and what they need. You develop and write things differently than you would if you think you have to do it just for your company.
That matters if we are building code that we want people to be able to maintain for many years, that others will be able to deal with when we are not around to be able to deal with it, for unforeseen things. There are some new types of I/O devices we hadn't thought about. Microsoft is doing very well in terms of showing us many different types of I/O modes, interaction modes, that we are going to be having with Surface and Towel and all these things.
There are going to be many different interaction modes and a lot of software we are writing may have to be adapted in the future to be able to work in these different modes. These may have to be adapted by people who are not the people who did the original development, to do things that were not dreamed of by the people who did the original development.
In the book, you discuss the issue of durability -- that software written today may need to run many years in the future. How does this work in a connected, cross-platform world?
The thinking that others will be modifying my product, that I will be interfaced to something that I didn't think that I'd be interfacing, is the way you make something durable. Because that is more likely to be able to survive changes and be able to be moved into new situations as the world around it changes.
Standards, well-known open standards, are important. The important thing is not that you are open source. The important thing is that the tools that you use to develop are tools that you will be able to use in the future, or that you can use other [compatible] tools in the future to do your development. If you use a proprietary language and the developers of that language stop advancing it, and suddenly hardware changes and you need to be able to change what you are doing, and the tool you are working with is no longer supported, you are in trouble.
We saw a lot of this discussion during the Microsoft Open XML and OpenOffice Format standards battle.
That is a very tough situation. In the old days when you wrote the various types of software, the save format was not defined. The save format was a serialization of the data, and the serialization was done by serialization code that was automatic. You don't define the save format in advance. You define what your program programs and then it saves what it saves and can load it back up, because it's the same code and is just serializing and unserializing it. That's hard to go backwards and say let's define something that does that.
What's happened in some of the world is we just say, "Let's just sort of start from scratch with certain standards." And in many ways we did with HTML, we sort of started from scratch. And now with some of the more advanced versions of HTML, especially CSS, we got to start from scratch again in certain areas. We're not talking about 100 percent backwards compatibility, but on the other hand we are getting better and better at figuring out how to write a spec, about what something does, what we have to do to have interoperability. With the case of Microsoft they have the issue of backward compatibility and their installed base and also business models, and that gets complex. A lot of people got to see that played out, because it involves tools that are central to many people's work lives and to various businesses.
So what can developers do to ensure their software stays viable?
One of the things is you are supposed to use loosely-coupled rather than tightly-coupled [links] between components. And to make sure you use standards and well-documented ways to couple between the different components that you have so it's easy to replace one component with a new version of a component without messing up everything else. Also, make it difficult to assemble things in bad ways without knowing it. Also, instrument what you build, really well. Have lots of ways to instrument it, so you know when you make a change whether it is working or not.
There are powerful lessons from the world of physical engineering and infrastructure management in your book. Can you talk about that?
A really instructive situation was the one at Three Mile Island, that I lifted little bits of from a book called "Normal Accidents." You see how different systems are coupled together and how problems can occur where you won't see them, and where you think something is happening but really something else is happening. You make a change based on what you think is happening, but because you couldn't see what was really happening you do the wrong thing. These things happen, especially in complex systems.
You should instrument your system, which is actually good for testing anyway, and make dashboards that people can see whether the thing is working. A lot of instrumentation... seems like extra fluff. Well, it turns out that may be the canary in the mine, letting you know what is happening.
And when you build something, assume somebody will have to fix it. Make sure when you comment things, you comment things that way. You provide affordances for them to make it easy. If you have certain testing code, you may want to leave it in and comment it out. And make it so that it's very obvious when the wrong data comes in. Even if you accept bad data, be very strict in what you produce but very forgiving in what you accept in data. Still instrument it so you'll know in advance that things have changed from what you expect.
So there is a real priority placed on preserving situational awareness. That was certainly a key issue at Three Mile Island.
Situational awareness is a wonderful term to use and one the military uses. You want to be able to give developers and people who are administrators situational awareness of your system, and build that throughout your system so that new components fit into that too. That makes it much easier to be able to find out if you can make a change.
You can also foresee where certain things are going to go. We know that people are going want to go from knowing what the situation is today to being able to look back on where the situation has been over time, and be able to ask what-if questions over about the data today and yesterday. They are going to want to mash up things that you used to mash up manually, they are going to want to automatically mash them up together. Look for the leading edge of [corporate development] to get an idea where things might be going. What might be cool or leading edge today might be required in your company in two to four years.
What if we reverse the analogy. Would I want, say, to drive over an open source bridge or live next to an open source nuclear power plant?
Well, a lot of the designs of things, physical things, are that way. So, yes of course you do. An awful lot of the Internet is built on open source infrastructure. What you're concerned about is do you want random people maintaining something that you don't know about, etc. That's a wrong view of open source. Open source refers to the ability of other people to be able to get access to the source code and do things with it if they want. But there are many manifestations of that.
What you don't want is a proprietary product. How do you know how to trust it? I mean, you have a throat to choke, but what if that company goes bankrupt?
You can often trust things a lot more if you can see how they are built, and with open source you can see how they are built. And you can have an independent, third party do testing for you. If it is proprietary, how do you trust them that it is being tested, that they are actually giving you the actual code, etc?
There is some open source stuff that is extremely robust and on which we build things that we really depend upon and that your life is dependent upon it. It isn't because it's open source or not, it's the particular piece of code and how that particular piece of code was vetted and checked that matters. It has nothing to do with how it was actually built. Though the open source model gives you some options in being able to check whether it is good or not.
How many people were involved in the creation of VisiCalc? Is it possible to map that experience and the powerful innovation it created, to the massive software undertakings we see today?
In the end an individual developer is producing an individual part of what it is they are doing. Sometimes that part is an entire application, sometimes it is a cog in a much bigger machine, so to speak. What you want is the totality of it all together. Unless you have the totality, you don't have the application that you want. That has always been the case.
What's nice today is we have a lot of small devices that are forcing us to rethink a lot of things and we're ending up with much more complex interaction on much simpler bases in some cases. That I think is good, as we rethink some of these things. But there are many applications that can only be built by a large army, and hopefully the tools we're building make it much easier to coordinate that. In the end you are still having armies of people working together, composing something together. And it is inherently going to be messy.
This is the old reengineering situation with businesses. You look at the business and say that we built this process in the business around the way things used to work when we only had U.S. mail and things were shipped this way, and we only had paper and the relationship between companies were this way and we couldn't communicate that fast. Now we can communicate instantly, we can share data immediately with suppliers and customers and we don't have to have those armies of people and build a procurement system that works that way.
Now is a great time, in a downturn like this. You may have the financial pressure, but now you can actually sit back and say how can we build to be able to make something more appropriate for today that will actually be cheaper and save us money so that if we don't get an advance, if things don't turn around that fast, at least we'll be spending less money in the future. But if things do turn around, we'll be in a better position to be able to deal with the world in a way people haven't, and our costs will be less. Historically that's happened. The companies that invest that way during the downturns and all have been able to come out better.
All these years after you crafted the first PC-based spreadsheet application, the simple fact is that the same metaphor remains dominant. Does that surprise you?
Yeah. A lot of us tried to supplant it with other ways of working. We tried with our TK Solver, which involved thinking more in terms of equations and all that. Lotus tried with Improv, some of which is in pivot tables today. We've all hoped we could figure out a way, but we haven't yet. I think we will eventually maybe figure it out, but it happens to be a good metaphor, just like the word processing metaphor really hasn't changed much since the early days I was working on it.
There are some metaphors that just are appropriate ways to work with certain types of data. The question is, are there other metaphors we can come up with that are useful for a large portion of the applications that we now put into that? But just because one tool goes doesn't mean they'll stop using the other tool. People still ride horses. There are certain places where sitting on top of an animal is a good way to traverse those areas.
What would you like people to take away from the book?
I hope that people will find the book inspiring and help them open their eyes to some of these things. The goal of the book was to help you get a certain mindset, certain backgrounds in ways of thinking, to approach problems that can be helpful in dealing with the evolution of technology and how regular people have to use that technology.
What are you doing now?
I'm still at Software Garden. The main product I am working on right now is called Social Calc, and working with a company called Social Text. The base engine is an open source spreadsheet written in Java, which we are integrating into their enterprise level wiki and social software system. The same engine is being used on one laptop per child. The interfaces are a little different, but it's the same calculating engine behind them.
Is it a relief to have the book behind you?
Yeah, I'm really happy to have it done. But it's very helpful to be able to point to the book for certain things. I was able to actually put together material that had been separate and juxtapose it, so you could much better see what the ideas are and how to approach them. The things are much clearer when you put a lot of things together and look at it from today's eyes.
Well, some of the passages definitely took me back to the mindset I had at the time. It forced the context on me.
Well, good. I tried to lay out the book in a way that made it obvious so you were aware when you were going back and going forward. Especially for younger people who haven't gone through that and to get a feel for it, and for older people too who enjoy remembering it, to understand this constant evolution and how it works.