3 ms·

How's the code maintenance on that? Just imagining what 'long now' code looks like!

• wpietri 14y ago
  Great question! It's something I thought a lot about. When we originally did the project, I engineered for long-term sustainability. I picked Java because even then it was obvious that Java was the new COBOL. Which had its drawbacks, but that meant high stability and longevity. I avoided complex dependencies; it ran by keeping all data in a single process and writing everything out to a set of XML docs on a filesystem. There the bet was that Moore's Law would progress faster than the data set size or the usage volume; that turned out to be true. The only real dependencies were on the core Java and Java Servlet stuff, plus an XML library. That simple architecture made it relatively sysadmin-friendly. Data was backed up by a simple script that just checked everything into CVS every 15 minutes. When they needed to move it to a new machine there was just setting up a standard Tomcat container, dumping in the WAR, and pointing it at the data. So there was never any significant downtime. I also wrote a bunch of unit tests, so that in theory it would be easy for another developer to pick up. Only a couple of other devs worked on it, though, so it's hard to say how much that helped. But I was really happy to have the tests a few years later when we reved it. Eventually it got rewritten in whatever their in-house dev was using so it could be more integrated with the existing accounts. The original code base lasted a decade or so, though, so I'm satisfied with how most of the initial choices worked out.