Slashdot Mirror
Dan Bricklin on Software That Lasts 200 Years
Lansdowne writes "Dan Bricklin, author of VisiCalc, has written a great new essay identifying a need for software that needs to last for decades or even centuries without replacement. Neither prepackaged nor custom-written software is fully able to meet the need, and he identifies how attributes of open source might help to produce long-lasting 'Societal Infrastructure Software'."
I think the trick is to use simpler hardware, which is easy to replace.
Take todays computer: motherboard with one big black chip, CPU on it, network card also one chip on it, videocard is too impossible to figure out how it works. Due to the integrated design, you can't fix it if it is broken. And in five years you won't be able to replace it one-on-one.
On older hardware (8 bitters), you were able to repair it yourself because you knew how it worked and you know you were capable of replacing a failing chip. Even if you didn't have exactly the same chip, you can use one of a newer family which did the same but would be capable of switching much much faster.
bash$
Remember Y2K? Did anyone notice that the world didn't come crashing down on Jan. 1, 2000?
It seems that all those old mainframes running programs from the 60's weren't in such bad shape after all.
This is an over-simplification of course -- people did have to do some work to make sure there weren't any "Y2K" problems.
We've had software and computers for ~30 years now
Going back 200 years, we only began the proper industrialization and everything was pretty much running on steam.
I think it's flawed to try to design software that lasts for decades or centuries.
The technology is constantly evolving, and as the hardware changes, so does the software.
If the hardware developement continues as it does, in 2200 we, or the people then, might be working with hardware running at terahertz speeds with 4096 bit architechtures.
Probably that's an underestimatement, since the evolving curves tend to be exponential.
I don't really think they would still need the software someone wrote for windows 95 200 years ago.
There are no atheists when recovering from tape backup.
Societal infrastructure is the key part here.
;) ) as a matter of fact, EVERYWHERE was very very different
..... Come to think of it - only some things change.
How many democracies are older than 200 years? How many governmental structures have survived 200 years? Bridges may last that long, but 200 years ago, Ireland was a very different place. America was a very different place, England was a very different place (see Ireland and America for why
200 years ago, the Americans loved the french for helping them in the civil war, the english hated the americans as barbarians, the Irish as "Paddies" and the Irish hated the english. The English hated the French
Back to the point - Software, or those parts of it that do qualify as societal infrastructure will have to change, simply to keep up with the rate of societal change and anything that lasts for 200 years is a very fundamental tool indeed.
Johns: Well, how does it look now? Riddick: Looks clear.
The point that the author makes here is really that without electricity we will lose great parts of recent history.
When I was at secondary school, in Britain during the 1980s, we participated in a UK-wide project to create a modern version of the "Domesday Book", the 11th-century record of people and property.
The project we worked on was recorded onto a (state-of-the-art) laserdisc so it would "last through the generations".
Last year I read an article saying that dedicated enthusiasts were desperately trying to assemble a working laserdisc system, in order to archive all the data collected just 20 years earlier.
Moral: it's not just electricity we need to worry about - media and the equipment necessary to access specific media is vital, too.
This is where the serious fun begins.
There are already legacy COBOL programs that are key pieces of many businesses. Some of those are almost 30 years old. Not really exciting code, but still important to many businesses.
The nature of technology is to evolve over time. Only the most basic tools we have haven't changed significantly over time: things like the knife, the hammer, etc. Even the screwdriver has seen significant development in the 20th century (Torx screws, for instance).
Only those things for which the underlying rules don't change can remain constant over time. Software is especially vulnerable to change over time because the platforms it depends on, both other pieces of software (like operating systems) and hardware, change significantly over time. 200 years ago, computers weren't even a glimmer in Charles Babbage's eye.
And as much as technology has changed over that period of time, so have the needs of society. And since software is written to fulfull those needs, it's absurd to even ask it to live much longer than a lifetime. About the only kind of software that could possibly live that long would be games, and even then only a select few have that kind of timelessness.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
there is an important difference between tools and infrastructure. true, much software is used as tools--for accomplishing discrete tasks that evolve as societies and technology evolves. but much software--databases, routers, control devices for physical infrastructure, etc--is used more as infrastructure; that is, as a resource expected to be reliable and predictable by many users and necessary for accomplishing other tasks that ride on top of it, including employing new tools.
infrastructure, because of its multi-user character and the fact that other things are designed to work on top of it, has to have lasting standards--if road lanes suddenly start to become half or double the width, then cars, trucks, traffic flows, etc will all be affected. even if some small technical reason might make it be reasonable to change them, their character as infrastructure means that the long term reliability of how they work is more important than short term technical considerations.
in other words, it would probably be silly at this point to try to design user interfaces, web browsers, etc. that last 200 years, because they are still rapidly evolving. however it makes a great deal of sense to start designing standards for data storage and interface, as well as actual 'infrastructure' software to last a long time because more users (including developers of more 'tool-like' software) benefit from its stability than from its instability.
I love the way that everyone presents written records as a good example of a "perpetual" medium which surpasses digital.
You may note that the author says "you can read 100-year-old newspapers *on* *microfiche*". This point practically jumps up and down to be noticed - even in the world of printing, paper copies are not seen as suitable for long-term storage, due to difficulties of preservation and physical bulk. So these paper copies are transferred to some other medium for long-term storage. This medium relies on readers existing - if all companies making microfiche readers went out of business (which probably won't be too many years ahead) then the microfiches will be unreadable. And the microfiches themselves are fragile - a scratch in the wrong place will make it difficult to read, and it's on plastic which will degrade over time.
Why should digital be any different? If you want ultra-long-term storage of digital data, use punch holes in gold sheets. Otherwise you use a storage medium which gives you a reasonable storage size and reasonable data security.
On reading the data back, suppose microfiche readers went obsolete and you couldn't buy them. The method of reading the data is still known and recorded, and can be reconstructed by someone needing to get the data back. Similarly, the most common bulk storage methods today are the CD-R and the DVD+/-R (tape backups are practically obsolete). Now the standard for data storage on CD and DVD is, well, *standard*. So if in 200 years time someone wants to read one back, they could build a CD player from first principles.
Grab.
- Move the software to a new box (but similar) since the old one is worn out or not fast enough or
... In practice this is not too difficult since you can either just copy the binaries or buy new ones orThis I would not call a real change and is not too expensive.
- Move the software to a new (or much changed [the current] version of the same one) operating system.
This is expensive as there is a lot of recoding that must be done and then work configuring it on the new platform.
Note that the above is only valid if the software being copied does not really change it's functionality as the customer has not changed the requirement spec.One of the nice things about Unix (Linux/...) is that you can still run very old software on new boxes with at most minimal changes - I still use code that I first wrote some 20 years ago.
There has been much assumption in this discussion that the whole system (hardware, OS, software) has to live unchanged for many years; I think that is missing the point as the true cost of software change is only big in case (2) above.
Note that some software does need to be regularily changed, eg payroll - because the governments change the rules every year or two.
I think that the fundamental reason that construction industry generally succeeds in producing bridges that don't fall down is the existence of building and planning regulations that require product to be of a good standard before they are sold. For example, in the UK if a bridge falls down and someone's killed it's corporate manslaughter and the MD is going to jail. Perhaps what we need is more regulation for the software industry ;-) For example instead of customers paying for software support maybe it should be a legal requirement that VENDORS pay software support and insure via a third party to guarantee support even if they go bust.
"As a writer / novelist you might want to spellcheck your sig.
Well, hardware can be worn out, but you can replace it, component by component, as he has suggested.
The problem with software is, as long as there is proprietory formats (or if you don't have the source codes), you can forget about what he calls "societal infrastructure software". If the government is thinking about being able to retrieve its data 50 years from now, better enforce that an open data format be used in your application, right now, and with clean and precise documentation. That means, no MS Word format, or something.
To extend that, the database files would be troublesome too. Anyone knows the internal structure of the Oracle database files?
My first job, out of school, and the first day on site, was to crack some database files of a system of a dead vendor. And there's no API (was in the early 90s), coz it's some PC software. The company has its customer info and accouting info in that DB, and must migrate it to another system which was still alive. There were about 300K records of all kinds, and no way to retrieve the data, except display them one by one, then copy it to another system. The alternative is to print out the whole thing, and re-enter in the new system. The system was critical to the company, but it has some serious bugs, but no one is going to fix.
What are you going to do with that? Well, good thing I was fresh out of school, and learned my data structures well, and the files are not encrypted. After one day of cracking, I figured it was some weirdo B+tree plus some kind of trie, and some more acrobatic tree structures and pointers pointing to all directions (probably for indexing or fast access). Another day to figure out enough of info, and by looking at the relationship in the application, to retrieve the data from that dead system.
That was easy enough. But if I were to brute-force retrieve from Oracle, that would be another thing.
Governments can enforce that vendors must provide proper documentation of their software data formats before a deal is struck, especially if the system is going to run national infrastructures, such as IRS, etc. Especially when the system costs in the hundred of millions (if not billions), why don't they enforce that? I would be multibillionaire if I knew the answer.
The idea of software that lasts 200 years reminded me of a discussion on the radio the other day about the origin of a joke: "I've had this broom 50 years, its had 5 new heads and 3 new handles". The identity issue played with here dates back at least to Plutarch's Ship of Theseus - if you keep replacing parts of a thing, until no original parts remain, is it still the same thing?
The relevance to software is captured with an example: Is Linux still Linux? How much remains of the kernel originally published by Linus? Would would you say that Linux has been around for X years (pick X to suit)?
Most people would agree that it's still Linux. What Linux, the broom, and Theseus' ship have in common is that they could be modified to meet the demands of time, while retaining their identity.
I've always thought that maintainability is the highest virtue software can strive for, above other quality-oriented goals like being bug-free, or performant. If its buggy, but maintainable, it can be fixed; if its slow, but maintainable, we can make it faster. I think it could also be argued that software, like Theseus' ship, needs to be maintainable to last 200 years; but the version 200 years from now may not resemble the original in the slightest.
Just my 2c
Baz
Um. Welsh?
True, there are additions. However, it is still possible to read welsh from 200+ (600+?) years ago and translate that effectively into current welsh/english/whatever.
Your word 1.0 doc containing that welsh however, is a different matter....
and a huge part of this is hardware support and, interestingly enough, storage bandwidth. You see, you have to migrate data from obsolete hardware/media to newer hardware/media, but in the near future the amount of data stored on obsolete hardware/media may become too large to transfer to newer hardware/media before it dies/decays/whatever, simply because the throughput of the transfer mechanism is too low.
HAND.
When i design projects, i tend to think more about keeping the data clean, simple and robust over time, rather than the ease which certian applications can reproduce it.
For example, when i designed KML, the idea was that it was meant to be a robust format that could be defined outside the context of any word-processor, and ultimately aimed at HTML, TeX, etc. At the moment, it is Regina REXX's job to render my markup. Nothing stops this from becoming Perl's or CEnvi's job! It's just a matter of writing a new parsing engine.
Because it is not something like HTML or TeX or RTF, i have considerable control over the format, and i can map several internal styles onto the same output, eg like {emphasis} vs {bold} in html. But the thing can be to the structure of the document.
It is more data standard, rather than program standard that is important. The latter is also important, since we don't want to either run dusty decks or old programs.
But what can you expect from an upgrades-driven market?
OS/2 - because choice is a terrible thing to waste.
When I was a young programmer, I was shown a water quality analysis program used by an English water authority that some colleagues of mine at ICL were particularly proud of. Not that they'd written it. It was running on an ICL 2900 series mainframe running VME. But the software wasn't written for a 2900 series, so it actually ran on ICL 1900 emulator, running MOPS. But the software didn't run on a 1900 series, so the emulated 1900 was running an emulator of an older English Electric computer whose designation I've forgotten. But the software wasn't written for the English Electric computer, so the English Electric emulator running on the the 1900 emulator running on the 2900 was running an emulator of the world's first commercial computer, LEO, for which the software was actually written.
When I saw this program in 1985 it was already thirty years old; it was still being used because it was still useful. If it is still in use it will be fifty years old, and (as 2900s are now very rare) is probably running under a further layer of emulation on an x86.
Any Turing equivalent machine can, in principle, emulate any other Turing equivalent machine. Of course, true Turing equivalence requires unlimited memory, so in practical terms it's only possible to emulate machines which have less memory than the machine that's doing the emulating. But it's reasonable to suppose that the machines of 100 years in the future will have at least as much horsepower and at least as much memory as the machines of today. So they will be able to emulate the machines of today.
A program written today may not be able to fully exploit the user interface features of a machine of two hundred years hence, any more than a BBC emulator can exploit the full graphics resolution of a modern workstation. But what a modern workstation can do is a superset of what the BBC Micro could do, so it can be emulated without compromise.
In other words, hardware compatibility is a non-issue in making software which will last and which will remain useful.
I'm old enough to remember when discussions on Slashdot were well informed.
In A Deepness in the Sky, Vinge posits a collection of software of ancient origins that handles all of the Qeng Ho's automation. This software is never replaced, but simply evolves as better ideas appear. While not technically open source (the Qeng Ho considered this software to be one of their proprietary advantages), it is open to every member of the group. By the time of Pham Nuwen, it had existed in some form or another for literally thousands of years, and over that time had been inspected by thousands of people.
[ home ]
...I agree heartily, but were the United States is concerned, this will probably never happen. The brand of capitalism that currently drives the U.S. is not friendly to goods and services that are expected to last a long time. In the past, you could buy a TV and the company would guarantee it's picture tube for up to ten years. These days you're lucky to find a TV with a five year guarantee on the picture tube and in most cases you are forced into buying an extended warranty that you have to renew.
The way that homes were built in the early part of the 20th century, those homes could be expected to still last up to 100+ years. These days, the cheap 'lick em and stick em' jobs that people pay hundreds of thousands of dollars for are certain to start falling apart in 10-25 years. I know this because I used to work on some of them. The materials are not meant to last. Many of the homes develop probles with the plumbing, roof, even the electrical in some cases. A lot of these homes can't stand up to tornadoes as well as the old houses could. There was a neighborhood in a city south of me where all the bran new houses were torn apart by a tornado. These houses were built in the late 1980s and 1990s. Within a few blocks, there were a few old farm houses that were unscathed. My point is that houses these days are made of crap, more expensive and are not built to last. They are essentially disposable after one generation grows up in them (while having to fix problems).
This is all evidence of the disposable, recurring payment culture of the U.S. today. I exclude other countries even though many of them have the same problem, but to a lesser extent. Those other countries are fr more likely to try and build a long-lasting, open source infrastructure. When I was a kid in the 70s, recurring fees were rare other than utilities and mortgage or car payments. Today, you can get nearly anything for a recurring fee. Although all the fees themselves are small, they total to whopping bills if a person needs or wants all those goods and services. Whatever happened to the day when you could buy something and it was yours. 100%. No strings attached. No recurring fees. Just yours. Sure there are a few things, but keep in mind that recurring fee or not, they are not built to last. Durability is anathema to profit in the new American way. The idea of having long-lasting, open source/free software is going to have a lot of opponents in the American software business soley because there is money to be made.
Un-news
In A Deepness in the Sky, Vinge posits a collection of software of ancient origins that handles all of the Qeng Ho's automation.
If you calculate the offset between the starting date of their oldest calendar and the epoch date of their software, it seems that their software is based on something written in the '70s, or at least that's when its calendar started.
Things that make you go hmmm...
One of their projects was to build a clock that could last a thousand years.
Their current project is to build a clock that would last 10,000 years. It would tick once per year and the cuckoo would come out on the millenium.
More successful clocks are the ones in Salisbury and Wells Calthedral. They've been in more-or-less continuous operation since the 1380s and are working now.
The Wells clock looks like it was more ambitious than the Long Now project. "As well as telling the time on a 24-hour dial, it shows the motion of the Sun and Moon in the sky, the phase of the Moon and the number of days since the last new Moon."
The lesson for the Long Now folks is that if you want to build something that runs forever, build it out of cast iron and replace the parts every few hundred years.
Another problem is the advent of the GUI. Give a user, or even a programmer, a text-oriented application today and be prepared for much wailing and gnashing of teeth. As someone who started writing programs on mainframes, it doesn't bother me, but I've seen users look at me like I'm some kind of Martian when I give them a command-line program to solve a problem, even though it is supplied with step-by-step documentation on how to use it.
Where are we today? I don't believe that there has been much progress made in recent years. You can write portable programs in COBOL, FORTRAN and Ada. ISO Pascal and ANSI BASIC seem to be near extinction. Portable programs are theoretically possible in C, but the pitfalls and temptations are many. I'm not a database programmer, but I would hope that there is a portable subset of SQL that would support the portable use of RDBMS. Why should I know or care that the system is using Oracle or SQL Server?
Mea navis aericumbens anguillis abundat
I used to work for a rather large telco-datacenter. They were using software built in 1970, to provision internet connectivity.
Telnet in (pick a username and try PASSWORD for the password) 75% of users were set up with default passwords. 50% of the active users were employees who left the company several years prior.
My team coded a new system from the ground up. Taking into account all the changes in the past 30 or so years. It was large roboust and elegant. Anyone who used the old system was completely blow away by the new system... Except the lead consultant from Accenturd. After 5 mins of our hour presentation, he cut us short and went on to be little us.... "anyone can code", " its just a website", ya know your company hired US to do that FOR you.
In the end accenturd decided that our 30 year old system would be just fine with a few modifiactions.. Sure the old system needs a team of 60, vs the team of 6 our NEW system required. But thats of little consequence.
$1 million - accenturd charge for simple modifications to a 30 year old system.
..VS..
Free ground up system built by internal employees, who worked with the old system on a daily basis.
The final descision was made by the person who originally spent the $1 million to accenturd. Seems he didnt want to admit he wasted $1 million for something we coulda gotten internally, for free.
There is no reason code should be running 30 years. I can assure you the original developer never intended 30 year life cycle on his code.
Old code still WORKED, that coder impresses me.
Old code was way obsolete, managment depresses me.
WrongWay
The author describes a lot of what's wrong with software development right now. Being on the admin side of things, I've often had to deal with very buggy stuff custom-written by an internal IT department. Lots of key systems at large companies are still running on either the original hardware or upgraded versions of the platform. (There was an article a while back about VAX finally being killed by HP...that should tell you something.) Any improvements are hindered by the original framework (think screen-scraping apps, multiple file format translations, etc.)
Civil engineers also run into this problem. For instance, take any large city whose highway system was built more than 50 years ago (NYC and Boston come to mind immediately.) No one ever dreamed that everyone would have their own car and stop using the trains/buses/ferries to commute to work. Therefore, overcapacity was never seen as a problem, and the rush hours just get longer every year as everyone tries to stagger their commutes. And since the roads are right next to buildings, in-place upgrades are very rare.
I think that once the whole IT labor market shakes itself out, software engineering will become another branch of traditional engineering. Just like power plants, dams, airports, etc., we're now dependent on computers, and it's time to put some standards into place. Software needs to be built such that it's portable, easily understood by a similarly-trained engineer, and conducive to improvements. In other words, it needs to be able to outlive the coder.
There is a software and hardware system that my company is designing to be maintainable until 2048. It has a long and well funded development cycle. We are developing version 6.0. Its funny though, the product has only ever been tested since we developed it over thirty years ago. And the design goal is to make it so well and in such quantity that it is never used. What is it?
Software however written is capable of running for as long as it is viable to the market. It's not an issue of hardware or interdependency between software sources. It's that our market and general theory of technology is destructive/creative in nature. We rebuild software not because it isn't capable of running for centuries but because the users of that software have been emboldened to think creatively about new applications. Our clients could run the software they have for a long period of time. We build platforms that support 5-10 years of enhancement. But the market whether external or internal requires us to innovate rapidly. To create software that last centuries you would need to kill the creative process that is technology. The social process that defines us as humans.
You've observed the environment and drawn the wrong conclusions. Yes, software companies release add-ons. My software company is just releasing version 1.4 right now. Is that because we all sat around in a boardroom, smoking cigars and laughing about how we were going to screw our customers out of money?
Actually, it comes from two reasons. First of all, we never have enough time to deliver all of the features we would like. Software release schedules are driven by sales cycles, so when the cycle rolls around, it's time to ship, so that means we need to cut off development for QA some reasonable amount of time before that.
Second of all, we have features in our 6th release (the point releases aren't as simple as they look) that, quite literally, I didn't even know existed when I was writing 1.0. We have other technologies and ideas I did know about then, but didn't know that customers would want them.
And as far as document types, I can open Word 97 docs in Word ver_whateverversionIhave. Microsoft gets zero bastard points for backwards compatibility.
I see a lot of crap here on Slashdot about how software companies screw people like this and that, and I just wonder how people think we have the fricking time.
I think this whole 200 year software stuff is wildly naive for the above reasons. A great quote I heard once said something along the lines of: When you place a 500 pound weight on a bridge, you can be reasonably sure that it will also support a 50 pound weight. The same is not true of software. I think what Bricklin has failed to grasp in his analysis is that what we're going through right now is it's own industrial revolution. First OO, then widespread use of patterns, relational databases...we're figuring out vastly better ways of doing things in software. At some point, we'll have as concrete (natch) an understanding of how to build software as we do of bridgebuilding, and then we'll settle into stability.
Slashdot, circa 3500 BC: Uzan of Ur bemoans having to rebuild the stone bridges every 10 years.
If your bitterest enemies are people who hack the heads off civilians, then I would say you're doing something right.
You can't worry about your software working for that long until your hardware can last that long.
;-) I wish I could be around then to be proved right or wrong.
Oh, nonsense. Consider the well-known "Hello, world." program in the K&R C "bible". It's been around 30 years or so, and the hardware they were working on now only exists in a few museums. But that program is still in routine use on millions off computers.
Note also that K&R included not only the code for the program, but the commands to compile and execute it. They correctly pointed out that this information covered the initial implementation details in most software, and once you had it working on a new system, you had soved the major problems in getting any software running on the new system.
And note that, after more than a quarter century, their sample code to compile and execute this valuable little program still work on millions of computers, without changing a single character.
Funny thing is, you can't say this about the equivalent programs in most other languages. I've seen attempts to do the same (code + compile if needed + invocation) for any number of other languages and OSs, but I've seen very few successes. Usually code that's only 10 years old will need tweaks. But if you have a standard-compliant (ANSI) compiler and a standard-compliant (POSIC) OS, you can type in this standard program using any editor, type in the compile command to any shell, and type in the invocation to that shell, and see the expected greeting appear on whatever "terminal" hardware you are using.
I'll bet that this little program will still be around and will still work 200 years from now. Even that bizarre "a.out" name, though I expect that using "-o hello" in the cc command will also work as it did in 1975. (And the program will still have the same subtle bug as the original did.
But so far, the signs are that this won't be true for many programming languages or OSs. The idea that code should be reliable in the long run seems to be something that's beyond the comprehension of few language or OS implementers.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
...not necessarily self-modifying, but at least self-upgrading. For instance, imagine a system that is part of the "societal infrastructure." This system is running a database... we'll assume for the moment that it's MySQL. MySQL releases a new version. The database (either automatically or at the DBA's request) patches the running binary. There is a short delay of lag while the caches are repopulated, and then the new version is running. Perhaps a "checkChangelog()" function is called, reading a machine-readable changelog to determine if there's any changes to input/output/config files that it needs to know about... no downtime, no kill -HUP, nothing.
I mod down pyramid schemes in sigs.
In the United States, the copyright lasts life+70 years for copyrights in the name of an individual for works published in 1978 or later, 95 years in the case of a corporate-held or anonymous copyright for a work published in 1978 or later, and 95 years for any work published from 1923 to 1977 inclusive (with some caveats about renewal rules allowing some to expire earlier).
So, for original 1977 Apple II ROMs, copyright currently expires in 2072 in the U.S.