5 ms·

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

• pedalpete 13y ago
  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 13y ago
    >> 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 13y ago
      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
  • AnimalMuppet 13y ago
    Modularity: This is my grandfather's axe. The handle has been replaced three times, and the head twice, but it's still the same axe. Flexibility: You have no idea what changes this code is going to need to undergo over thirty years. You don't even know what all the axes of change are. Try to implement it as cleanly as you can. But here's the thing: You have to maintain that cleanliness through all the changes. Refactoring is vital. You can't leave it a mess after a change five years from now, or even 20 years from now, because you (or somebody) is still going to have to work on that mess for a decade or two. This means that your biggest challenge is to create a culture that will survive for 30 years - a culture that will insist on leaving the code clean for those yet to come.
• brudgers 13y ago
  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 13y ago
  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.