Ask HN: Who is building “long lived” software?

I'll agree that the half-life of things we're building sometimes seem rather short.

Two systems I worked on that had over 500k users each, have both been switched off and are not longer 'alive' on the interwebs. One for internal political reasons, the other was absorbed into the main portal for the parent company. (Some of my code still runs internally, but the public-facing stuff is drastically different)

And my other web-apps were internal/intranet web-applications. That said, they're still running and useful - even 12-15 years on... so it's not all bad.

But the public web (particularly e-commerce related sites) seem to have short lives these days. Perhaps Open source might be your better bet if you want to leave some sort of legacy.

I've built an operating system for running highly automated Escape Rooms (an interactive play space for people to solve puzzles and enjoy the experience.) Our buyers are expecting to run each room for 5+ years. Our oldest continuously running room is about to hit its first birthday.

I do have an embedded systems background, but the technology for this application is a step higher-level than that. It's 99% Python3 running on a network of Raspberry Pis.

ive worked for banks and pension companies and they pretty much run COBOL mainframes for the core business. Lifetimes easily 40 years or more, and I cant see the systems being replaced any time soon.

im quite envious of them at times when Im plugging away doing Java development as they have a legacy that most developers wont have

I write risk analytics software for banks and fund managers. This type of client is extremely conservative - once the system goes in, it's probably going to stay in use for 20 years or more.

Gave a lot of thought to what languages are future-proof and decided to stay away from the whole Microsoft suite after seeing many perfectly OK apps written for Visual Basic having to be scrapped.

In the end I went for C++ for speed, portability and longevity. I'll bet there will still be backwards-compatible C++ compilers in 50 years which means my code will still be usable.

I started writing backend software for banks, oil and gas distribution and utilities around 20 years ago. I wouldn't be surprised if most of it was still running in some form.

I think it's a matter of finding an industry that is conservative or for which the underlying business structures / calculations don't change. Myself, I've been working on real estate feasibility analysis software for 12 years now, and the product had existed prior to that for perhaps 10 years; the core calculations have made the journey from Turbo Pascal -> Delphi -> C# .NET. The next iteration of the project is a web-based version, but it'll still (re)use the same core calculations. The target market - real estate developers and investors, mostly - don't necessarily want anything new and exciting; their needs are best served by software that delivers the same calculation results over many years, and that they are used to working with.

I've been working on e-commerce platform that been around 7+ years with the same core logic.

Since we use DDD, we can swap out technologies but keep our core business logic.

Embedded would be a field with longer-lived software, yes.

I used to work on helicopter avionics. I'd be surprised if the projected service life of the software was less than 30 years.

Downside: everything is amazingly old-fashioned, even during prototyping.

Good software is very persistent. Client doesn't care about underlying technology as long as it performs. Freelancing for 20+ years I have active sw written in VB6 that still sells after 18 years. Nowadays wherever I start a new project (web of course) I try to pick mature, fresh (if possible open source) frameworks, components etc. since you simply never know how long you're going to maintain it.

Yes. It's a lot harder to do this for web stuff because stacks tend to churn so fast that you end up forced to rewrite perfectly good code because the framework it's built on decided to introduce breaking changes in a new version.

Pick your tech well, and you can pull it off though. S3stat has major bits of heavy lifting in place that I wrote in 2006. There are even older infrastructure pieces such as an ActiveRecord-style data layer that I pulled across from another project I built in the early 2000s.

A lot of that stuff was written in C# to target .NET 1.1. And it still works today because Microsoft understands the value of backward compatibility.

I feel your pain though. I just watched Amazon shut off one of my Lambda projects because it was running an old, deprecated, version of Node.js. Old, meaning, I kid you not, One Year Old.

From what I can tell, stability directly correlates with product-market fit. Thrashing on features and depending on the latest technologies, in my experience, has always been driven by either developer impracticality or stakeholders' lack of market understanding.

Sorry for the self-promotion, but I wrote this article after being frustrated with the "iPhone mindset for application development": it’ll be obsolete in 6 months anyway, so who cares?

http://www.programmerfu.com/2017/03/17/the-everlasting-app.h...

Right now I'm working on ways to extract the meat of my applications into plain, sustainable code. Then I can still use the new hotness when it's appropriate, but in a way that doesn't lock me in.

You can expect to write software with a long (10+ years) shelf life in astronomy. Especially if you write observatory infrastructure code. Things like data-flow software, science archive code, pipelines etc. Also most end-user analysis software tends to stick around for a long time: in some cases 20+ years, which of course is good and bad.

The issue you describe isn't technical. It's mostly social. Your colleagues don't question the sense of updating the frameworks for no reason.

It's not that CSS/HTML will stop rendering. So you can just stay with 5 year old framework if you want. e.g.: old Twitter Bootstraps and old Angulars will still work, so if you've written code in that, don't touch it. But people get excited about updating, because they like to get features they won't be using.

The long-lived software is hard, and make sure you don't leverage yourself on the other end. Writing stuff to survive many years can be stressful. And you'll see 10-year old hacks and workarounds in the code as well. Just look at some Linux/FreeBSD kernel code. You can also read what Raymond Chen is writing about Windows kernel hacks to make customers happy.

But yeah: embedded, and everything infrastructure related should be long-lived. Even mobile: when writing www.sensorama.org I've mostly used ObjC stuff even though Swift existed for 3+ years now I believe. And all libraries and proprietary apps are and will be ObjC for many, many years. There's just not enough reasons to upgrade.

Standard Notes

http://standardnotes.org

https://news.ycombinator.com/user?id=mobitar

Not what you're looking for, but I made a Twitter bot that has been running uninterrupted and unmodified for 3 years.

Also, the Space Jam website is up and unmodified since 1996.

I've been writing Photoshop Plugins in C for over 15 years (since the shareware days). And while there's been tweaks for things like Vista compatibility and the transition to 64-bit, much of the core logic is still the same code I wrote in 2001 & 2003.

Notably, I still get customer support enquiries from people running the binaries I published in 2003 - literally an EXE installer they found on an old magazine cover CD-ROM or outdated shareware website. And in some cases, the official binary people are buying from my site today is completely untouched since 2011, and still sells - just not at the levels of 2006. (But I don't recommend that, I'm in the process of updating & releasing new versions of all of them.)

I'm on a team that is working to build "long lived" software. We are in the beginning phase so there is a lot of changes (we've gone from C# applications to now a micro service architecture using Web API) but once we get a stable backing it shouldn't change. The platform is for handling Medicaid visits for patients of our clients (I work for a third party administrator for health care). The goal is to architect it to be extensible for each new client onboarded and then just be done with it (save for updating .NET versions when needed).