Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Rot

permacomputing.net

Post reply on HN
Print view View original

151–160 of 252 posts

Re: Software Rot

#151

Post by BobaFloutist »

Ygg2 wrote: post #81
codeflo wrote: post #74

Earlier quoted context omitted.

> People want your software to have more features, have fewer bugs, and not be exploited. So you and every one of your competitors are on an update treadmill. If you ARE stable, you'll probably fall off. If you are on the treadmill you are accumulating code, features, bug fixes, until you either get off or a faster competitor emerges. Runners on treadmills don't actually move forward.

Kinda the point of the threadmill metaphor. If you are standing on a threadmill, you will fall right off. It requires great effort to just stay at one spot.

But adding features isn't staying at the same spot.

Re: Software Rot

#152

Post by Faark »

veggieroll wrote: post #139
icameron wrote: post #18

Nobody has a better ecosystem of “industrial marine grade code rot resistance” than Microsoft. That I can run the same .NET web app code compiled 20 years ago on a new Server 2025 is an easy experience unequaled by others. Or the same 30 year old VBA macros still doing their thing in Excel 365. There’s a company that knows how to do backwards compatibility.

I don't have experience with .NET. So that's nice to hear you've got a reliable setup. But, this has generally not been my experience with Microsoft. There's tons of old programs from the Windows 95-XP era that I haven't been able to get running. Just last week, I was trying to install and run point and click games from 2002 and the general advise online is to just install XP. There was a way (with some effort) to ge…

HellCopter in my case. Few years ago I still somehow manages to get some edition running, no luck this time. Rot is a thing and the retro gaming & archival communities a blessing.

Re: Software Rot

#153

Post by esseph »

antepodius wrote: post #113
esseph wrote: post #93

Earlier quoted context omitted.

You just described all software, for the decades it often runs. Entropy sucks.

The point of the article is that this does not have to be the case, and is not the case for all software.

There's a lot of software that ends up lasting for decades, through multiple OS platform refreshes. Normally there's a small platform/OS team that gets to slog through gardening that mess while everyone else is long gone.

Re: Software Rot

#154

Post by hu3 »

donatj wrote: post #132
forgotmypw17 wrote: post #2

This and Lindy Effect factors a lot into my choices for what to use for my projects. My choice for a project I want to be as maintenance-free as possible are special subsets of ASCII/txt, SQLite, Perl, Bash, PHP, HTML, JS, CSS. The subsets I choose are the parts of these languages which have persisted the longest. Using the Lindy Effect for guidance, I've built a stack/framework that works across 20 years of differen…

I love PHP, however since around 7.4 they have become pretty happy to make breaking changes to the language, including recently in ways where you cannot satisfy older and newer versions of the runtime simultaneously. I end up spending often a couple weeks of my life on and off fixing things after every major release.

Was it related to magic quotes or global variables created from user input? If so, the writing has been on the wall for over a decade for these.

Re: Software Rot

#155

Post by croemer »

vdupras wrote: post #115
dgoldstein0 wrote: post #70

Earlier quoted context omitted.

So one effect I've seen over the last decade of working: if it never needs to change, and no one is adding features, then no one works on it. If no one works on it, and people quit / change teams / etc, eventually the team tasked with maintaining it doesn't know how it works. At which point they may not be suited to maintaining it anymore. This effect gets accelerated when teams or individuals make their code more ma…

Maybe it's a documentation problem? It seems to me that for a piece of software to be considered good, one has to be able to grok how it works internally without having written it.

Not per Naur, in his seminal "Programming as Theory Building" he claims that documentation doesn't replace the mental model that he original authors had developed: https://pages.cs.wisc.edu/~remzi/Naur.pdf

Re: Software Rot

#156

Post by tracker1 »

immibis wrote: post #116
noduerme wrote: post #69

I wish I could write all the business logic I write on an NES and never have to worry about requirements going bad. I guess the thing is, if you're writing anything on top of a network layer of any kind, eventually it's going to require patches unless you literally own all the wires and all the nodes in the network, like a secure power plant or some money clearing system in a bank that's been running the same COBOL s…

Building on bedrock is one extreme; the other is to become extremely fluid - build on quicksand but do it efficiently every time the quicksand shifts. AS3 may stop being useful, but if you can use some tool to recompile AS3 code to web JavaScript, you suffer no loss.

That's kind of my approach... KISS to the extreme. Something that's easy to replace tends to become surprisingly long lived and/or ported easily. I wrote a test launcher and client api for SCORM courseware in the early 00's. That code was later turned into a couple of LMS products, ported through a few different languages on the server and still effectively exists today. The DB schema and query code is almost exactly the same as baseline, except I didn't implement one feature that a decade in came across a course that used it and helped implement it.

Still friends with the company owner of that code. So I've had a bit more insight into follow-up on code over 2 decades old that isn't so typical for anything else I've done.

Re: Software Rot

#157

Post by tracker1 »

BobaFloutist wrote: post #150
codeflo wrote: post #72

Earlier quoted context omitted.

That's probably true, but you're describing incentives and social dynamics, not a technological problem. I notice that every other kind of infrastructure in my life that I depend upon is maintained by qualified teams, sometimes for decades, who aren't incentivized to rebuild the thing every six months.

If you're asking why software has more frequent rebuild cycles than, say, buildings, or roads, or plumbing, it's because it's way cheaper and easier, can be distributed at scale for ~free (compared to road designs which necessarily have to be backward compatible since you can't very well replace every intersection in a city simultaneously), and for all the computerification of the modern world, is largely less essent…

It's like the difference between building a Bird house, Dog house, people house, mansion, large building and a sky scraper... it's different levels of planning, preparation and logistics involved. A lot of software can (or at least should) be done at the bird or dog house level... pretty easy to replace.

Re: Software Rot

#158

Post by jeberle »

noduerme wrote: post #69

I wish I could write all the business logic I write on an NES and never have to worry about requirements going bad. I guess the thing is, if you're writing anything on top of a network layer of any kind, eventually it's going to require patches unless you literally own all the wires and all the nodes in the network, like a secure power plant or some money clearing system in a bank that's been running the same COBOL s…

Despite it being everyone's favorite shame language, COBOL's DATA DIVISION makes it uniquely well-suited for long-term stability. Common practice is to avoid binary fields. This means what you see in your program is what you see on the wire or in a file.

Re: Software Rot

#159

Post by tracker1 »

bloppe wrote: post #55
codeflo wrote: post #44

We as an industry need to seriously tackle the social and market dynamics that lead to this situation. When and why has "stable" become synonymous with "unmaintained"? Why is it that practically every attempt to build a stable abstraction layer has turned out to be significantly less stable than the layer it abstracts over?

At any given moment, there are 6 LTS versions of Ubuntu. Are you proposing that there should be more than that? The tradeoffs are pretty obvious. If you're maintaining a platform, and you want to innovate, you either have to deprecate old functionality or indefinitely increase your scope of responsibilities. On the other hand, if you refuse to innovate, you slide into obscurity as everyone eventually migrates to more…

They aren't still supporting 14.04. How do you get 6? There's one every other year, and they retire one shortly after a new one comes out. They're also pretty quick to shutter non-lts release support each lts generation.

Re: Software Rot

#160

Post by tracker1 »

gjvc wrote: post #98
codeflo wrote: post #44

We as an industry need to seriously tackle the social and market dynamics that lead to this situation. When and why has "stable" become synonymous with "unmaintained"? Why is it that practically every attempt to build a stable abstraction layer has turned out to be significantly less stable than the layer it abstracts over?

post a link to a stable repository on github on this site. watch as several people pipe up and say "last commit 2020; must be dead" source code is ascii text, and ascii text is not alive. it doesn't need to breathe, modulo dependencies, yes. but this attitude that "not active, must be dead and therefore: avoid" leads people to believing that the opposite: unproven and buggy new stuff, is always better. silly counter-…

I don't assume it's dead based on the last commit. I will look a little further and see where it stands. If there hasn't been a commit for a few years AND there are multiple pull requests that have been sitting unmerged for years and dozens/hundreds of really old issues... then, I'll assume it's dead, and often open another issue asking if it's dead, if there isn't one already.
Post reply on HN