Interesting, my gut feeling is the opposite. I think code is being written today that will remain running for something approximating "forever". Stuff will work and people won't want to change it - or things will be so intermingled that they won't dare to.
My opinion is the technology used for the most successful and robust back-end systems will remain long after Im gone, while that which is purely for the HMI will continue to be as fluid as it is now, simply because behaviour evolves based on individual and institutional retained knowledge.
Another part is front end vs back end. I still get contacted occasionally on various back end and infrastructure stuff I built from 1995-2010, while I never hear from anyone about the user facing code. Front end has been replaced many times over, while the back end infrastructure just ticks away quietly...
I've contributed almost 10k hours to 100s of projects in the last 10 years, and most of them are still alive and have only grown in adoption. (Also it would suck if all that time went into the bin a few years later!)
From my experience, here's a ranking of how long code lives:
* Proprietary "webcrap" and plumbing logic at companies. This dies the fastest (6-24 months).
* JavaScript frameworks and tools, open source. "Dies like flies" -- many of them, short intense life, then everything dies down and the buzz moves to the next swarm.
* Proprietary backend code. Lives 5 years, then gets rewritten or dies a long death.
* Open source code in dynamic languages. 5-10 years, then mass extinction events end some lineages, such as "The Tertiary Era" (Python), "The Discovery of the Fundamental Theorem of Write-Only Code" (Perl), and "The Birth of the Script Kiddie" (PHP).
* Open-source code in static languages (Haskell, C++, C). Usually around already 10 years before I started contributing, and showing no signs of getting old.
C/C++ are very stable and backwards compatible, Rust tends to be more aggressive at the moment of changing things.
Honestly I think the investments made into web technology right now are so massive and pervasive that I wouldn't be surprised if we still use something that looks a lot like the web stack in 50 years, simply because there'll never be a good moment to dump all that baggage when you're so deep in it. I don't think we can look to the past of computing to understand its future, I think we have reached in the past ten years or so a critical mass and penetration into the fabric of society that the rules are just different know than they were in the 90's.
Unless the way we interact with our computing devices fundamentally changes (say, a shift from visual/touch to, idk, voice or brain waves or whatever), I have a hard time seeing how there'd ever be a big shift from the web stack to something else like, say, the shift from Win32 apps to web apps. Hell, even if there is, the web might just embrace it. My day job is web-based AR...
The stack will evolve, sure, and maybe at the end there's nothing left and the clients won't know HTTP at all anymore... but I can just as easily see us just piling more stuff on, because I honestly think that, even with voice assistants and AI and whatever, most people are still going to produce and consume text and images from a device a lot like a phone for many years to come, simply because it's a system that works well for humans that have eyes and fingers and pockets.
And if that's the case, then what's going to cause a seismic shift in platforms, when almost all software developers are web developers, and all devices run web applications? And if the stack doesn't change, why wouldn't some of the code stick around, if the business or organization that invested in it does? Some businesses now might replace twenty-year-old code just because, but at least part of that is because of how software stacks have changed and aged, and I think the sheer amount of "webcrap" that's being excreted by people like you and me is going to slow that rate of change right down, even if it doesn't feel like that in the middle of all the framework churn.
Same goes for webcrap; I have some horrible php and jsp prototypes from the early 2000s which have been running production ever since.
You should always worry about vendor lock-in. Vendors only do it because they gain something by it, namely reduced competition. Reduced competition is always bad for the consumer.
As a consumer, having 50 nearly-similar options to choose from is arguably worse than having only a few. With 50 choices you’ll get an entire sub industry devoted to “helping” you make a choice, and you’ll likely miss out on certain economies of scale.
As a vendor, it’s a lot easier to understand, support, and build products for your customers if they are only using your products.
There are obviously negatives to vendor lock-in, but framing it as entirely negative is misleading.
Whilst that is doubtless true, that does not make anything better for customers.
If a company’s customers solely use their product, and not a mix of products, it’s much easier for the company to support and build new features for their customers. This is just a fact of reality, and one benefit of customers limiting the number of products they use.
Pointing out beneficial properties of consolidation and specialization doesn’t mean I support monopolies—I absolutely don’t.
Ideally, there would be one car. Ford. Ford would be the only vendor for cars, and Ford would be the only car vendor. We'd have the technology approved by Ford and all of the technology approved by Ford, including black paint, carburetors, tetraethyl lead, and, through a special deal with Radio (formerly RCA), AM radios tuned to Radio, the only Radio company and station in the world.
These vehicles would be simple to maintain, in that the only maintenance option is to ship them to Ford, and simple to customize, in that you cannot.
And anyone who attempts to modify their Ford would be subject to legal penalties, up to and including bomb-making, just as if they'd tried to destroy any other institution.
Since you asked, my opinion is that there's a healthy tension between too many choices and not enough choices, and we should strive to maintain that tension. Which requires an objective understanding of the tradeoffs, instead of knee-jerk reactions to the phrase "vendor lock-in".
Standardization drastically reduces the cost of choices by letting you make them independently, a healthy market increases the chances that there will be many good choices, transparency increases the chance that you will pick one that is good for you.
A small number of complicated interrelated choices would be manifestly worse than a large number of independent mostly good enough choices. This is why its mostly ok that there are a billion different cars. Most of your choices are good enough for most purposes and you don't have to pick your phone, your route home, your brand of gas station based on your car or options.
Having few choices is virtually always bad. The converse is a difficult position to defend when instead of fewer choices one nearly ought to always wish for easier ones.
I think "business logic" is indeed temporary. With very few exceptions, most code you write for someone else will not stand the test of time. In fact, most of the companies I've worked for do not exist or have greatly changed over the years.
MIT/BSD software is a little better.
And strangely - GPL software does stand the test of time.
So with the BSD license somebody can take your work, improve it, distribute it under a proprietary license and supplant you in the market. Compare macOS or iOS installed base to FreeBSD.
But then the codebase is henceforth tied to that company. If Apple is dead in twenty years then probably nobody is still using the iOS kernel (and not because they switched back to FreeBSD), but if Google is dead in twenty years most likely Linux is still popular all over.
https://en.wikipedia.org/wiki/XNU
And Mach too is available under BSD-like terms.
Arguably one can just call it Mach, as the bsd server part was delivered as part of Mach.
- software written for a company has a lifetime ~ the life of a company
- MIT/BSD software may be adopted and not shared.
- GPL software would be shared widely and changes would be given back.
I'm just speculating and I have no idea what the real statistics are.
The primary reason the software development field has evolved to be preoccupied with saving/re-using/inter-op code is because of the difficulty of building even the most trivial piece of software.
Unfortunately code hoarding is simply a reflection of the age-old human flaw of wanting to recoup sunk cost, you assume if you've invested a lot of time into something, it must be worth holding on to for as long as possible :)
If software was as easy to make as a piece of office stationary is easy to write on, no one would care about code reuse/saving/interop...you don't see anyone saving post-it notes or even excel docs for indefinite reuse.
Then I realized that what I'm actually creating and maintaining is not code. It's the mindset behind the code, and the skillset to convert ideas to working pieces of software. My legacy would be to learn through experimenting, and to help others learn the same.
Who has a true legacy outside a small minority of philosophers, artists, scientists and political leaders?
Not everyone wishes to leave a mark on the world after we are gone. There are entire philosophical branches dedicated to the idea of embracing mortality and accepting that which makes us human.
Bloodlines die out or change enough to not be recognizable.
Tests are what you need to invest in. When you test all of you business use cases in an abstract (perhaps even no-code) way, you are truly independent. You can rewrite the system very quickly, if you had a test-suite that allows for quick iteration (TDD style) and does not depend on implementation details.
Given just the code? Well good luck migrating to another cloud vendor. You will probably introduce one million bugs on the way.
Good luck with that. lol.
- The only stable APIs I've seen, if an API exists, are production financial APIs, because money is involved.
- DynDNS has been knows to change input and output parameter types, breaking calls
- Even Twilio has changed a fundamental API path (!) in the past couple of years, breaking SMS API calls in 2019
- Facebook only supports API version N and N-1. Hope you're not on N-2 and there's a sudden version bump!
(I say production APIs, since even payment gateways often have flaky dev/qa gateways that you can't reliably do automated tests against. Past companies that I worked at had to test against prod gateways with their own personal credit cards.)
Otherwise, if you want an API, ensure you choose a product/partner that offers/supports one.
Wishful thinking, though, in many cases. When software dictates the workflow, the code _is_ the business process documentation. Add a new function to the code? Did you go and update the docs, too? Takes serious diligence, takes bigger teams, hard for a small business systems department to keep up with that. That's why they use low-code platforms, aside from the skill gap (i.e. once you can really code, you tend to not want to write business systems stuff anymore)
And the crazy thing is, in today's world of microservices and hyperfocus on horizontal scaling, I would still implement it in pl/pgsql, and indeed, I'd expect it to keep ticking for the next 20 years as long as the company stays in business.
That's a huge big IF. In many if not most cases the only reliable documentation of a system is the running code itself.
"I take the view that applications come. Applications go. Applications come again and go again. But - the data, the data - oh, it stays and stays and stays and is used by application after application after application. And if you store your data perfectly for "the first application", it'll not be good for the future ones. And I don't see tons of data that isn't used by many applications (need many views of the same data). See, my goal is the data - knowing that applications are like Mayflies but data is more like a tree."
Your counterclaim to this piece is that humans aren't a thing that matters. Do you have reasons?
Egress costs make sure of that!
That's why I think as long as you have documented and defined your methods (i.e. business logic) well, and your data is portable, you shouldn't worry much about vendor lock-in in the long run.