Hacker News Reader

Comment by irrational | Hacker News Reader

10-20 years?! Holy Cow! Other than huge software projects (like Word or Mac OS - and even then...) is there really software that still has that kind of maintenance window? I've worked for a Fortune 150 company for nearly 2 decades. There is not a single piece of software at the company that has not been rewritten from scratch (usually due to business changes) at least once every 10 years. I can't even imagine something that would still be useful after 10 years (honestly, even 5 years seems like a stretch). Just think - software written 20 years ago would have been written when the WWW was still soiling its diapers.

View on HN

I'm working for a healthcare insurer and I don't believe anything has been rewritten since they went from mainframe to .Net.

The previous application I worked on is over a decade old (and it shows). The current application I'm working on is about 8 years old.

Neither applications has any sign of being replaced. Which would be insane, as they both have roughly a decade of laws & regulations and business lessons embedded in them. Despite the state of especially the older application, I don't see how rewriting the entire application would fix anything.

At best parts would be rewritten. And the parts I'm thinking about wouldn't be rewritten because of technical reasons, but because of the way they work. The prime example is a part that only 1 person, a business user, understands.

I work in medical robotics and I can tell you that a lot of our code is quite old, and we have a culture that code you write will stay around. Some things don't change for example optimal control algorithms, while others things are very difficult to change such as network routing. So, while the applications get re-written on the 4-10 year time frame parts of the OS are 15+ years old.

> I can't even imagine something that would still be useful after 10 years

Ah the HN perception bubble.

Good code last longer than that. Bad code gets replaced.

Good code is replaceable. Bad code is hard to get rid of.

Some code sticks around because it's great at what it does. Some code sticks around because it works if you don't touch it and is impossible to delete due to various kinds of dependencies.

All code is replaceable. It's bad APIs that are hard to get rid of.

Most POSIX APIs, for instance, are confusing, obtuse and unnecessarily imperative but still good enough in spite of being 40 odd years old. There's way too much code that implements or calls them to justify making significant changes as this point.

We are talking years and decades, where "replacing" is applied to entire applications, not chunks of code.

Especially in SOA, it can be cheaper to replace a poorly written service than trying to rewrite all of it over time.

If it ain't broken, don't fix it.

> If it's broken but in familiar, known ways, with runbooks, and the cost of rewriting it is way higher than supporting it for 5 years & hopefully we'll move away from the business model which requires it, don't fix it.

I have started companies 15+ years ago that I sold which still use (a lot of) the same code. You think (I thought) that would never happen but I think this idea that every company rewrites everything is not all that common. Banks don't, but the small startups I work with don't either. Frontends get redone, there is refactoring and library updates but most (unless trivial tiny systems) just stays the same. You need to think that they run a business and that business is not software development usually. So if there is not a pressing reason to replace things, why would they allocate money for that?

I also consult for Fortune 500 companies on a regular basis, and most of them still have core business processes running on mainframe code bases well older than 10 years. No one is doing major greenfield development on mainframes, but they still exist all over the place.

I'd love to read more about what it's like doing mainframe consulting. Do you own or know of any blogs in this area?

I don't know of any. I don't consult for the mainframe systems themselves. Usually I get pulled in when the client realizes that their last mainframe developers are years away from retirement, and they cannot find any new mainframe developers to hire. That starts a mad dash to migrate/replace the mainframe solution without disrupting the entire business. Despite the existing codebase, these projects are very difficult because noone knows how they work anymore.

At one of my clients they had one mainframe developer left that knew their systems. She had already tried to retire, but they got her to agree to stay on for 5 years in return for bags filled with money. That meant they had 5 years to rewrite on a platform they could actually hire people for. 5 years to replace a system with decades of history.

I think IBM and their Z division would disagree. IBM Z Users: The 10 top insurers, 44 of the top 50 banks, 18 of the top 25 retailers, 90% of the largest airlines

That seems to agree with me? Mainframes are still in use everywhere. However, that statistic doesn't imply that those customers build their brand new greenfield capabilities on those mainframes.

IME most software will last that long, if it's remotely successful then it will at least make it to the 10 year mark. Business rarely changes drastically enough for a rewrite to make financial sense.

About best you can hope for is a new "epoch" that forces a rewrite. In the MS world we went from classic VB and VC++ to .net, a lot of companies went through rewrites to keep up with that and some of that software is now nearing 20 years old. There has been a few other epoch like changes, terminal -> GUI, c++ -> java, desktop -> web, except for maybe the last one it's been quite a while since a new epoch has begun.

Parasolid [1] is 30 years old and is the dominant B-rep solid modeling kernel powering Solidworks, Siemens NX and Solid Edge. It's very difficult to see it being replaced as it is so entrenched.

Parasolid (written in a C dialect) was a rewrite of Romulus (written in Fortran) and that goes back to 1974. And that was a rewrite of Build that originated from Ian Braid's PhD thesis. [2]

I know people who are still working on the same Parasolid code after 30 years. Some of them

Disclaimer: Parasolid dev 1989-1995

[1] https://en.wikipedia.org/wiki/Parasolid

[2] http://solidmodeling.org/awards/bezier-award/i-braid-a-graye...

I recently finished making some mods to a PHP CMS to make sure it works fine with PHP7.1. The base of this code is 17 years old and is still used every day.

The CSS/JS on the frontend rarely lasts more than a few years, usually changed to due to design trends (flat, responsive, mobile-first etc).

Everything that controls hardware has tremendous maintenance windows. Trains, planes, industrial machines.

Most business critical software like SAP for example is also based on decade old codebases.

Wordpress is 14 years old.

It's probably a good reference project, when talking about maintenance (nightmares).

My business, https://www.filterforge.com/, is almost 12 years on the market since the release of v1.0 back in 2006. And if we also count the 6 years of initial development, that would be 18 years in total.

I also work at a similarly large company.

Some of our internal infrastructure systems are 10-20 years old - some could definitely do with a complete rewrite, but in the meantime, they're mission critical systems.

As for our products - some of them have even longer timeframes than 20 years.

I know of multiple finance companies that have Mainframe Assembler from the 70s.

Reply on news.ycombinator.com