Maybe I’ve had an atypical experience, but most places I’ve worked with teams of more than a couple of programmers there has almost universally been some sort of “just run this small thing in prod and keep it going” scaffold, which is often one of the oldest and least “shiny” pieces of infrastructure in place.
So I guess the system described in this article doesn’t sound all that remarkable to me, even in it’s longevity.
I think the real surprise of this article is that a piece of software written in 2008 is seen as ‘old’. Most of my jobs have involved codebases that dated back to the late ’90s. And I think that, in an ideal world, this should be the rule rather than the exception.
You’re right. Even when the piece isn’t “shiny” it can survive a long time. coughcobolcough
I love these stories of DIY internal systems that endured the test of time. It’s about solving a pain point, and sometimes magic happens and the solution becomes an unofficial standard.
Maybe I’m getting old but this story didn’t seem all that compelling. Can you imagine… an internal system for running code? IDK.
But wait, you’re forgetting the part where it continued to work for twelve whole years. Pure freaking magic!
(In seriousness, 12 years may be seen as long-lived for a Silicon-Valley-fueled company that sells a webstie. But a bank? Our standards should be a little higher than that.)
Yeah. I mean it’s “the most remarkable legacy system” and it’s written about banking software. I was expecting a literal dust-closet server from like the 70s or some old guy’s PC in the backwoods of appalachia.
12 years old software is legacy? I have such things running in production but never thought they are legacy. Perhaps because I built them…
Yeah, I wouldn’t call 12 years old legacy, either. Especially not when it’s written in a language that’s still popular.
Around 2007-2009 I worked on a system that was about 30 years old, with some of the code dating back longer than that. It was in the process of being replaced, but wasn’t scheduled to be fully decommissioned for another 5 years still.
To be fair it was written in a language version that was being deprecated. That means libraries were bit-rotten, certain things couldn’t be run locally without first downloading the exact runtime dependencies (rather than letting the package manager solve it automagically) etc. etc.
As far as I’m concerned it was legacy and the author’s work primarily involved making sure that twelve years later people could still use the damn thing after a good chunk of its requirements either moved on from its version or were obsoleted.
Having forgotten the optimistic tone of the article title I’d clicked, I read to the end expecting disaster.
Yes, that was my expectation too :)