I feel like this is heavily connected with the idea of legacy. I grew up in Scotland, and lots of the buildings, culture, etc, have been around for hundreds of years. It would be nice to feel like something I was building would last as long and outlive me. It doesn’t though.
Sometimes I think that this is just the nature of software development. Most of the stuff I build is built to solve an immediate business problem. It probably lasts 5/10 years and then someone rewrites it in a new language, or more often the task isn’t relevant anymore so the code gets deleted.
I find myself thinking that maybe if I’d been in civil engineering or something then I’d be building stuff that lasts, but speaking to people who’ve worked a long time in construction has taught me that it’s the same there. Most of the buildings that go up, come down again in a few decades once regulations/fashions change or the new owner of the site wants something else.
Every so often something like a Cathedral gets built, and those get built to last. But most people don’t get to work on those. If there’s a software equivalent of a Cathedral then I still haven’t found it.
People are commenting core OS libraries and kernels, but the Space Jam movie website from 96 is still up. I bet the guy that wrote that didn't think it'd be around nearly 20 years later, I hope it never goes down.
It's comforting to think that 2000 years from now, all that may remain of the early web and modern culture is the Space Jam website. Maybe Space Jam the movie will be looked at as our Gilgamesh or Iliad.
From the outset, the framing of a Web site as staying "up" (or going "down") is definitely an accessory to the mindset that leads to the effect observed. Rather than regarding Web sites as collections of hypertext-enabled publications like TBL spelled out in "Information Management: A Proposal", we have this conception of a Web page being something like one part software, two parts traditional ephemera. But they're documents. Merely observing this difference in framing and being conscious of the contrast between intent/design and practice can go a long way to addressing the underlying problems that arise from the practice.
I never saw this page before. Brilliant! Like catnip for nerds.
Disaster planning → Every byte of source-code history for SQLite is cryptographically protected and is automatically replicated to multiple geographically separated servers, in datacenters owned by different companies. Thousands of additional clones exist on private servers around the world. The primary developers of SQLite live in different regions of the world. SQLite can survive a continental catastrophe.
SQLite is awesome. TIL that its database structure is robust enough to have been chosen as one of only 4 Recommended Storage Formats for long term data preservation[0].
> "Recommended storage formats are formats which, in the opinion of the preservationists at the Library of Congress, maximizes the chance of survival and continued accessibility of digital content.
I'd say something like TeX might be a software cathedral, and even that one isn't going to last much longer than Knuth himself (almost everyone today doesn't run TeX, they run a compatible software platform, some are even entirely different).
But even a Cathedral changes over time, and your work may not last; but all human work is a shrill scream against the eternal void - all will be lost in time, like tears in rain. The best we can do is do the best with what we have in front of us. And maybe all the work you did to make sure your one-off database code correctly handled the Y38 problem back in 2000 will never be noticed; because your software is still running and didn't fail.
> pdfTEX is based on the original TEX sources and Web2c
So it at least ties back to original code. XeTeX appears to be similar but with even more extensions, but other of the "TeX" tools are complete rewrites.
Externally visible stuff: definitely. You really need something like TeX or by now Linux and some GNU Tools etc. to stand the test of time.
My very first job was to work on the backend of some software for internal use. You have probably all bought products that were "administered" in said software. When I worked on it it was 15 years old. It evolved over this time of course but original bits and pieces were all around me. And I evolved bits and pieces of it as did others. By now it's been another 15 years and while I know they did a rewrite of some parts of the system I bet that some of both my code and the code I found to have been written almost 15 years before I started there is still around and you and me keep buying products touched by that software without knowing. The rewrite was also done by at least one person that was around when the original was built. He learned a new language to implement it.ut he took all of his domain and business logic knowledge over.
Its even more funny because I knew the guy that wrote some of the code I worked with directly from a different company but I had no idea he worked there or that he worked in that project until I saw his name in the CVS history. Yes CVS. I personally moved it to SVN to "modernize". I hope that was recognized as "technical debt" and they moved to git but I wouldn't know.
I think this is by far the most common outcome for work. A chefs product only lasts an hour at most. Most jobs don’t create anything other than a temporary service.
That’s because most of the things we need are temporary services, of course. You need dinner. And gas to get to work. And a roof that will last 10 years. Etc.
That's a very romantic view of the life of a chef but I'm afraid that by an overwhelmingly enormous margin the output of a chef is servings of food not century-spanning recipes.
The comparison between developer and chef is kind of a stretch but there is a similarity of sorts. It could be argued that the recipes are analogous to the algorithms or patterns that we use day-to-day in software development, and that the servings of dinner are analogous to the applications we build. The algorithms/patterns and recipes might persist for a while, the apps and food have a shorter lifetime.
I'm not advocating for throwaway or disposable code (though I'm not above implementing a quick hack, personally) but I don't think we need to think less of ourselves or our profession because we're producing things which currently have a shelf-life of years or decades at most.
The Youtuber Max Miller's channel "Tasting History with Max Miller" has a number of good examples of old recipes for now-familiar foods. His Semlor episode[1] compares a recipe from 1755 and one from more modern times, and there are substantial changes.
When I was young I spent a year framing houses. I reflect a lot on how much longer those have lasted then so much of what I built software wise along the way.
It isn't necessarily software, but algorithms will likely last a long time. Euclid's algorithm and the sieve of Eratosthenes are still around. Researchers are still developing new ones. Just like building techniques may outlive the buildings that were created in their shadows.
Most code that survives 5 years survived for all the wrong reasons. That said, most code that's survived five years is often a profitable product with a reasonable human at the helm telling us needs to not to touch it
> If there’s a software equivalent of a Cathedral then I still haven’t found it.
Probably like, some parts of Windows or Linux, or GNU tools, or some thing like that that, while still being updated, also has ancient components hanging around.
> I find myself thinking that maybe if I’d been in civil engineering or something then I’d be building stuff that lasts, but speaking to people who’ve worked a long time in construction has taught me that it’s the same there.
Right. People who assume otherwise aren't spending much time browsing the relevant subjects on Wikipedia or historical registers or just paying attention to their municipality. Simple demonstration: look into how many Carnegie libraries that were built are now gone versus how many are still around.
Consider constructions that have survived thousands of years such as the Tarr Steps or Stonehenge, or more recent constructions such as roman roads, Dunfermline Abbey or St Bartholemew's Hospital.
These sorts of constructions have been repaired and re-set hundreds of times over their existence, and have sometimes gone through periods of destruction during war and natural disasters, disrepair then subsequent periods of restoration and reuse. At a certain point, very little or nothing of the original construction really remains, but you can nevertheless draw a line through hundreds or thousands of years of history.
Software may be more like this: continually rebuilt and maintained, but still physically or philosophically related back to some original construction. Nobody uses Multics any more, but almost everything in use today is derived from it in some way.
Why though? Does it really matter if something outlives you by 200 years? 500? On a not-that-long timeline like 10,000 years, nothing lasts. The "cathedral-like" timeline is completely arbitrary I think.
Imho, there’s freedom in accepting that nothing I produce will last a long time.
Games seem to have a longer shelf-life, or at least tend to be passed around for longer. Some of my Flash games from 15 years ago are still being passed around game torrents and still playable on Newgrounds, and the console games I worked on are still playable in emulators and part of rom collections (and the one physical game I worked on, a PSP game, is still available to buy used on Amazon).
Now, how many people are actively playing those games? Probably very few people. But at least it's still there when people get the urge, or decide to play through a collection.
I agree with your takeaway message, but the timeline isn’t completely arbitrary. From the perspective of humans appreciating things, there’s a difference between something that endures for .01x vs. 10x a person’s expected lifespan.
Because what matters is not the number you can think of, but the scale proportionate to human life / needs.
For somewhat related context: all my life until recently I rented, but now had become a house owner. My strategy with things I bought for daily use was that they were meant to survive until the next move. For many things it wasn't economical to take them with me to the new place. So, for example, I didn't want to buy a "proper" pan / skillet, and was happy with a teflon one just because it would wear off about the time I needed to move again. I could just throw it away and get a new one. Now that I don't intend to move, I'd choose to buy things that last, because cost of moving vs cost of garbage cleanup changed.
Now, when it comes to software, it looks like the industry is overwhelmingly motivated by short-term benefits, where, in principle, it shouldn't have been. And this is the surprising part. Lack of vision / organization leads to the situation where we never even try to make things that last. There are millions of e-commerce Web sites in the world, but they are all trash because nobody could spend enough time and effort to make one that was good (so that others could replicate / build on top of it, and also have a good product). We have the most popular OS, that's absolute garbage, both the core and the utilities around it, which is due to shortsightedness and even unwillingness to plan on the part of the developers. Same thing with programming languages, frameworks etc.
So, looping back to your question: why the magnitude matters? -- what matters is how your own planning compares to the lifespan of your product. Many times in my career I was in the situation where I was building an already broken thing from a design that was known to be broken from the start or very soon afterwards. And that had nothing to do with changing requirements, it had all to do with the rat race of getting a product to the market before someone else does / investor's money dries out. The idea behind "things that last" is that at least at the time you are making them you cannot see how whatever you are making can be done better (as in more reliable / long-lasting).
In the end of the day, what happens now in programming is that things that shouldn't outlive their projected deadlines do, or, predictably, die very fast. But we don't have any section in the industry that builds things to last. We just keep stuffing the attic with worn-out teflon pans.
Compare this to, for example, painters, who despite knowing that most of their work will likely be lost and forgotten, still aspire to produce "immortal" works of art, and if a picture takes a lifespan or more to make, then so be it. (In the past, some works of art were carried out by generations of artists, especially, when it comes to books where scribes were succeeded by their children who'd continue writing the book after their parents death).
To your point about buildings, I wish we considered the "technical debt" of our society's built infrastructure more. It seems we went very wrong with this habit of building and rebuilding on such short cycles, especially on large projects that have much longer lasting consequences on the more important infrastructure of our natural ecosystems. All that carbon burned to extract, produce, and transport building materials. All those sprawling roadways built over habitats and forcing people into unsustainable patterns of living, burning more carbon in their day to day to get around. This debt needs to be measured and it needs to be addressed with high priority.
But the thing is, that the ghost of the code lives on. Many times I saw specific database designs, and technical decisions all taken to accommodate a solution that didn't exist for a decade or so.
To invoke the RIIR train, probably a lot of fertile ground in being the definitive Rust implementation of "solved" foundational libraries: zlib, libpng, libjpeg, etc. Something ubiquitously used which has very minimal/no churn. As Rust usage grows, dependency on the original C implementation will diminish.
It will diminish, but never go away until POSIX foundations or graphical programming standards get replaced (most of them defined via C ABIs).
When I was mostly doing C++ and C on day job, 20 years ago, they were the languages to go when doing any kind of GUI or distributed computing, nowadays they have been mostly replaced for those use cases.
Yet they are still there, as native libraries in some cases, or as the languages used to implement the compilers or language runtimes used by those alternatives, including Rust.
Even those change substantially over time, even if they're not directly rewritten, things get updated and relocated.
It's like how the streets in Rome have been the same for much longer than many of the buildings have been standing, even though the buildings are hundreds of years old.
This is completely random, but you remind me of something that makes me laugh every time I use Google Maps navigation.
Last year I was messing around with my phone's text to speech settings, and I selected a male voice but cranked the pitch setting to the max. I proceeded to forget about it. For some reason when navigating, the voice is still the default pitch. Maybe about 1 in 20 turns at random though, the voice has the pitch cranked up to the max. It's rare enough that my 4 year old and I always burst out laughing when it happens.
Sometimes I think that this is just the nature of software development. Most of the stuff I build is built to solve an immediate business problem. It probably lasts 5/10 years and then someone rewrites it in a new language, or more often the task isn’t relevant anymore so the code gets deleted.
I find myself thinking that maybe if I’d been in civil engineering or something then I’d be building stuff that lasts, but speaking to people who’ve worked a long time in construction has taught me that it’s the same there. Most of the buildings that go up, come down again in a few decades once regulations/fashions change or the new owner of the site wants something else.
Every so often something like a Cathedral gets built, and those get built to last. But most people don’t get to work on those. If there’s a software equivalent of a Cathedral then I still haven’t found it.