Making software that's immortal

How long should an agency use a piece of software? Dan Bricklin, co-inventor of the first electronic spreadsheet program, thinks applications should last for centuries. Last summer, Bricklin wrote an essay about this idea called 'Software That Lasts 200 Years,' which was widely discussed within the IT industry. In IT circles, the notion of extending software longevity borders on heresy, given how companies thrive on rapid obsolesce and regular upgrade cycles. Still, Bricklin has argued, as electronic data becomes more central to our daily lives, the tools to manipulate that data are much like the roads, bridges and buildings we use every day. As such, he maintains, software should be commissioned and maintained in much the same way.Bricklin knows a thing or two about software. In 1979 he co-developed VisiCalc while he was a student at Harvard Business School. Although Lotus 1-2-3 eventually eclipsed VisiCalc in the marketplace, Bricklin has continued to work in the field, both as a consultant and a software developer. In 1985 he formed his own company, Software Garden Inc. of Newton Highlands, Mass., which he still runs today.Bricklin holds a bachelor's degree in electrical engineering and computer science from the Massachusetts Institute of Technology and a master's degree in business from Harvard University. Staff writer Joab Jackson interviewed Bricklin by phone.BRICKLIN: A change has occurred, which is part of [the evolution of] e-government. Citizens expect having access to all the old data and having real-time access to data.That wasn't the case in the old days. Then, you'd have someone go look it up. If you had to get data from more than one department, you'd have to make separate searches. Nowadays you expect to get all the records and have them integrated. It's not the same thing as when we had paper backups and the software was just a tool to help us. Software and electronic data is the only way today.The government is a long-term entity that works on the behalf of society. We expect the government to provide deeds and records and laws. Those are long term.BRICKLIN: You don't just try to construct a building as inexpensively as possible or build it as quickly as possible. There are minimum standards you must adhere to. Even though we're trying to do it inexpensively and quickly, there are certain things we do not do without. They just go without saying. If you don't do those things, you know the building will fall down. Or the building will be unmaintainable in the future. That's why we have building codes and things like that.We should use the same approach with computer systems. We should ask what are we willing to pay for, knowing that in the long term, as a society we can afford to do this.BRICKLIN: I think they have to be explicit about it. They have to have some very clear goals. It is still not a science because we are talking about an unpredictable future. So, it's kind of like human interface design. You can't know everything about what's going to be, but you can do evaluations to at least look at some best practices.One thing we have to do is separate out the data that needs to be stored, maintained and accessed from the particular programs that access that data. You need to decouple the different pieces because different parts will change at different times. You want to be able to change things only when needed, without having to change the whole thing.There's another thing we should determine if we start looking at long-term principles. Can the software deal with evolving environments? In other words, can the software, with just minor modifications or maintenance, deal with the evolving environment around it? Can the software itself evolve?BRICKLIN: One of the references is a book called Normal Accidents [by Charles Perrow]. Using the Three Mile Island accident, it talks about how there will be component failures with complex systems. Sometimes, components interact in ways that you couldn't foresee and very unusual accidents happen. That's where the idea of tight coupling was popularized. Perrow explains why tight coupling could be dangerous and why loose coupling has some advantages.I've been looking at how the idea could apply to building software that will have to live with unforeseen situations. For instance, when data will be used by some intermediary, what should the connections be and how complex should they be?We do know that some very successful interfaces have been very simple ones, for example the IP for the Internet. IP's simplicity made it possible for the Internet to grow in ways that were never foreseen by the people who created it. There are other protocols that are very complex and make it very difficult for people to see what is going on. Those haven't been as good.Transparency is another well-known principle for letting an operator, or somebody, know what's going on in an application. Things that are hidden, where you can't tell if something is working or not working, are very dangerous.So there are some guidelines, examples we can look to in order to learn how to build the connections among the different components in order to keep them robust, transparent and fertile enough for all the different uses that may come about in the future.BRICKLIN: What's interesting is that a lot of engineering principles apply to software, and those principles have been around for a long time. Some of the principles we use in civil engineering are the same principles that Galileo taught. For instance, when you build something a lot bigger than you ever built it before, you may have problems with scale.You need to watch out for that. Galileo wrote about it. An elephant isn't built like an insect. If you make an insect real big, it will fall over because of the way things work with scale. And that's true with a lot of things. You build a test program, it works great, but when a million people descend on it, it falls over because it doesn't scale well.BRICKLIN: I'm assuming that most software will be developed by people who are not government employees. So if a customer wants something a certain way, we should build it that way. We have to design our business entities around this long-term view. There are certain types of business entities we need but do not necessarily have. They are just starting to develop. We already have entities whose main job is to check for security or to check for various vulnerabilities. For certain things like this, you can spread your expertise around many products.That's one of the reasons that making available the source code [of an application] is important. An example is internationalization, which involves a lot of translation. Companies that specialize in inter- nationalization take the source code from the vendor, and they do the internationalization, which is not done by the vendor itself.BRICKLIN: We always thought that software could be replaced. We were careful in VisiCalc to make the data format very obvious. The 'save' format of VisiCalc was the commands necessary to recreate it in ASCII: 'Go to A-1 and type this and go to B-2 put in this.' So we actually had an upgradable format and that made it really easy for Lotus 1-2-3 to read VisiCalc, which it did initially.BRICKLIN: It is basically me. I do consulting. I give speeches. I also do some software development because I feel that to be able to talk about this stuff, I have to have some first-hand experience. I love developing. I love making software.