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

that should be the norm.

the reality is that is a strong ad against almost all modern frameworks, that may live for as little as a football season




Not really. Not automatically, anyway. Realistically, code lasting forever is, the majority of the time, some engineer’s nerdy wet dream almost completely devoid from any real-world requirements. “This code should last 20 years” should, for most people, be fairly low on the list of desires for a technology stack. In the vast majority of cases, the processes that the software seeks to automate will have been thrown out LONG before then. The business went bust and the only surviving copy is on some developer’s personal computer. Darlene from accounting left and her replacement likes to do things differently, so all this custom stuff was replaced with something off-the-shelf. Your $40B unicorn dating network very unceremoniously fell from the charts after Gen Z decided to throw their phones away and connect in person like we used to. After all that, you’re left there holding a perfectly functional(?) solution to a problem nobody is asking to be solved anymore.

Let’s be clear: I know that banks run on COBOL. Everyone knows that. Please don’t say it. I can name 5-10 other industries off the top of my head where this sort of longevity matters. But let’s not kid ourselves that the stuff we’re writing is even intended to last a long time.


>> But let’s not kid ourselves that the stuff we’re writing is even intended to last a long time.

Not my experience at all. I am literally at this moment releasing new version of private app framework that was created by few people (including me) about 18 year ago for few clients on long forgotten platform because some client (who is still paying support fees!) found some obscure bug building new application using this framework. The previous version was released about 8 years ago.


Longevity is very important in enterprise apps. Companies are full of small services / utilities which were developed many years ago, work for the most part just fine and need to be touched only rarely to fix a bug which just started manifesting, add a small feature or enable some integration.


>>“This code should last 20 years” should, for most people, be fairly low on the list of desires for a technology stack.

>> But let’s not kid ourselves that the stuff we’re writing is even intended to last a long time.

Well, it depends. If you write custom software for enterprises, they very much see it as a long term investment. Software grows with the company and is embedded in it. Nobody wants to pay for complete rewrites every five years..




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

Search: