
Ask HN: Who is building “long lived” software? - hn_throwaway_99
As a web e-commerce developer, I&#x27;m tired of building software that feels like it has a lifespan of 6 months before the next framework&#x2F;business model&#x2F;org change comes along. Is anyone building software with a lifespan of greater than say 5 years? Would I need to get into hardware&#x2F;embedded systems if I wanted to build something that was longer lasting? Any other developers that have made the switch?
======
jasonkester
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.

------
mb_72
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.

------
barelyusable
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.

------
SyneRyder
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.)

~~~
vram22
>I've been writing Photoshop Plugins in C for over 15 years (since the
shareware days).

Wow, that's really cool, Kohan. Do you also sell products developed in Xojo,
or do you only use it for internal projects of yours?

~~~
SyneRyder
Still only for internal projects so far, but I'm getting closer to a
commercial product release. (I've actually just finished a night of hacking in
Xojo, and added some charting features to the project schedule estimate tool
I've been making... unfortunately, the charts are forecasting that I'm 3
months behind schedule :) )

------
luca_ing
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.

~~~
cyansmoker
And technical debt keeps accumulating... Even when starting a new product,
lots of older code has to be reused.

~~~
romanovcode
What's the problem with "older code"?

------
spiggytopes999
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.

~~~
AnimalMuppet
Or at least mostly portable. There have been breaking changes to C/C++
compilers - mandatory prototypes comes to mind. Sometime in the next 50 years,
another such change is possible.

------
twooclock
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.

------
fpierfed
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.

------
glancast
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...](http://www.programmerfu.com/2017/03/17/the-everlasting-app.html)

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.

------
jetti
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).

------
davewasthere
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.

------
akulbe
Standard Notes

[http://standardnotes.org](http://standardnotes.org)

[https://news.ycombinator.com/user?id=mobitar](https://news.ycombinator.com/user?id=mobitar)

------
spcelzrd
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.

------
Schwolop
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.

------
fiftyacorn
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

------
thorin
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.

------
UK-AL
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.

