Hacker News new | past | comments | ask | show | jobs | submit login

I'd be curious to hear an example of that (I don't believe I have personally seen one that fits that pattern in the wild yet).



I used to work at a large software company. They had one giant monolith application, about a hundred different modules that did things from financial registration, displaying media. 30 years old, ported from clipper to delphi to .net. Lots of technical dept, but one issue fits the type of "pay-in-full". They only had a maximum of 3 gigs of ram to work with because the monolith was a 32 bits application. That was ok for most modules, but some did some rather complicated stuff that required more memory occasionally. It caused infrequent out-of-memory exceptions. The cause was one 32-bits library that was very hard to replace. It was used everywhere, and stored reports in a proprietary format, the company that made that library went out of business at some point, no source was available. The company prided itself on backwards compatibility, so it couldn't just dump the library without porting all the reports over.

As far as I'm aware, it's still a 32 bits application.


I'm not sure if it's "technical debt" but backward compatibility between versions can feel like this. Once you decide you stop supporting a previous version, you can rip out all that code (or strange compatibility code paths). Until then you're stuck with the whole thing.


removing a library? you can remove 100 usages of it but not until every single one is gone can you remove it.


porting to a backwards incompatible a language version? you can't use most of Python 3's new features while some part of your codebase is in Python 2




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: