

Ask HN: How do you architect software that needs to be maintained for 30-years? - spiffytech

A discussion[0] yesterday got me wondering: how do you architect a software project that you expect will be in service and maintained for 30 years?<p>How do you decide which programming languages, libraries, dependencies, and tools are appropriate to use? How do you forecast which design patterns are both helpful, yet easily recognized and used by those who maintain the project after you? How do you build in enough flexibility for the project to withstand 30 years of requirements changes and enhancements?<p>[0] https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7142356
======
pedalpete
First off, I think you might not be getting responses to this because you
labeled it a 30-year software project, which isn't what you're asking really,
you're asking how do you architect a product that will be maintained for 30
years.

Those are two VERY different questions. I came here expecting to answer not to
expect to develop for 30 years.

Ok, now for my answer. There are a few things you'll want to look at.

First, I'd argue you build very modularly. You don't know what the product is
going to need to do in 5 years, let alone 30 years. Building a product from
independent modules will allow future developers to add, remove or update
modules to reflect the times.

As far as languages, go with either what is popular today, or what you have
EVIDENCE will be popular in the next 10 years. I say evidence because if you
just hop on the next big thing (Go, Julia, etc) because at this point you
don't know how difficult it will be to hire developers that are familiar with
those languages in 10 years.

The libraries and dependencies answer is the same as the previous. Don't pick
something obscure that you think 'might' be popular in the long-term, go with
what's popular now or has evidence of popularity later. jQuery, Bootstrap,
Rails, Node.js all had massive amounts of interest right from the start.
However, if you can get away with not relying on a library, you should
probably do it. If you need something now to ship quickly, but don't want it
populating your project long-term, use it only in the modules that need it,
and that way it can be easily replaced later (I'm doing this with jQuery now
as Angular DOM traversal isn't great.. yet).

~~~
spiffytech
>> Ask HN: How do you architect a 30-year software project?

> you labeled it a 30-year software project, which isn't what you're asking

Good call - I've changed the title.

What sort of evidence do you think a developer should look for to tell whether
a language may become popular, rather than just plateauing with a strong, but
relatively small, user base? How strong should the evidence be to justify
choosing an up-and-comer over an existing major player?

~~~
pedalpete
You can use github as a decent judge of this I think. You're not going to find
any absolutes as to the potential popularity of a language, but I'd recommend
not jumping on the next new thing. Go with something that has at least a few
years behind it.

[https://github.com/JuliaLang/julia](https://github.com/JuliaLang/julia)
[https://github.com/rails/rails](https://github.com/rails/rails)
[https://github.com/scala/scala](https://github.com/scala/scala)
[https://github.com/joyent/node](https://github.com/joyent/node)
[https://github.com/ruby/ruby](https://github.com/ruby/ruby)
[https://github.com/sinatra/sinatra](https://github.com/sinatra/sinatra)

------
brudgers
Emacs and Autocad both use a similar model based on a core plus a powerful
command language...ie, the same architecture as LISP. That's not to say that
either was initially envisioned as a 30 or 40 year project. It's just that
their architecture has allowed them not only to survive but evolve
continuously alongside expectations and needs release by release.

------
bennyg
Most people have hit on the big ones, but I think the most underrated answer
is: Comments.

Seriously, comment the hell out of that code where anybody coming in at any
time can understand what's happening. Make it so that a technical director can
read only the comments and understand the entire system and it's dependencies.

