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

Why Does Software Rot?

overcomingbias.com

Post reply on HN
Print view View original

61–70 of 81 posts

Re: Why Does Software Rot?

#61

Post by mamon »

lifeisstillgood wrote: post #6

Three reasons: 1. The code is the same but the people using it forget / never knew the reasons it was built that way - and so it looks rotten for the job 2. Because requirements change and people try to make the old code do new things without cleaning up / refactoring correctly - so it now does neither job well, and looks rotten. 3. Because the environment / platform changes, the FTP server is moved to a new data cen…

I think that point 1. is caused by the fact, that the industry tends to divide programmers in two categories: most competent ones become architects and lead developers and are hired when you need to build new software system from scratch.

After the system is built you let the people who created it go, because you can't afford their salaries and hire younger, less talented people to maintain it.

So, instead of "software rots" i would say "software evolves to reflect the competency level of it's current maintainers"

Re: Why Does Software Rot?

#62

Post by PeterisP »

ArkyBeagle wrote: post #14
boznz wrote: post #10

Unless your sandboxed in a self contained hardware and software environment (such as an embedded system) you will eventually be screwed. (rot sounds like a gradual degradation its generally not in my position) Standards changes and OS Updates are the biggest culprit; The Vista update broke a couple of my old programs (written for Windows 95) due to the user access control changes, another was broke due to the fact it…

This is because there's little glory in simply making things work. There is glory in making things that look shiny and new. As they say, "Absolutem Obsoletum". And congratulations on understanding exactly why I prefer embedded systems - you don't have to keep chasing the dragon of the fashionable new thing ( which is invariably old wine in new skins ). It is not that there is no new wine it is just that proportionall…

Embedded systems seem to have all the same problem but worse - the difficulties to get an obsolete software environment working (possibly in a VM) to maintain a legacy program are insignificant compared to getting replacement hardware to keep a legacy embedded system working if some of these particular components haven't been manufactured for a decade, and you either have to port the system, throw it out and replace it, or enter the wonderful and pricey world of custom hardware manufacturing.

Re: Why Does Software Rot?

#63

Post by kd5bjo »

kazinator wrote: post #54
xyzzyz wrote: post #52

Earlier quoted context omitted.

strcpy() does, though.

What's wrong with strcpy? In a nutshell, we can only safely use it if we somehow know that the source string fits into the destination buffer. Those situations are few: basically, they involve fixed-length string literals being moved into buffers that are "obviously" larger. E.g. some widget_t object has a char name[256] field, and we initialize it by default with strcpy(new_widget->name, " "), or some bullshit like…

You're correct about the problems, and I would always recommend strncpy over strcpy for safety, but it's not quite as limited as you portray: You only need to ensure an upper bound on the string length that will fit into your destination buffer. In addition to literals, this can also be guaranteed by copying a string that's already stored in a container that's smaller than the target, such as a fixed-size buffer or database field.

Re: Why Does Software Rot?

#64

Post by imtringued »

hueving wrote: post #51
ArkyBeagle wrote: post #15

Earlier quoted context omitted.

Through the miracle of virtual machines, this is much less so. VMs are the NAT of computer systems.

If devs have to download a VM running an old OS with old tooling, the barrier to entry is getting quite high. I wouldn't touch an OSS project that made me do that, I would assume it was effectively dead.

It would be dead without the VM anyway.

Re: Why Does Software Rot?

#65

Post by specialist »

jussaskin wrote: post #9

Software rots if you can no longer set up the exact tool chain and environment (compiler, build tool, OS version, external database, etc) required to build and run it. Even interpreted languages suffer from this problem as features are subtlely changed - by design or accident. It doesn't matter if your project is using an ancient version of VC++ or a two year old version of NodeJS. If it doesn't keep up with the late…

Digital entropy.

Preserving order requires constant energy investment.

Just an analogy, but I find it useful.

Re: Why Does Software Rot?

#66

Post by specialist »

jussaskin wrote: post #17
ArkyBeagle wrote: post #15

Earlier quoted context omitted.

Through the miracle of virtual machines, this is much less so. VMs are the NAT of computer systems.

Less so, I agree. But give it time - older VM image and container formats will probably rot as well.

Extending the digital entropy analogy: decay rate, half-lives.

Re: Why Does Software Rot?

#67

Post by specialist »

fallous wrote: post #40

In most of the cases discussed in the article, it's not the software that rots but instead the users and/or organization that decays. When a system is created, it is generally designed to solve a known set of problems encountered by an existing population of users. Over time, the tool creators, original users, and the current problem domains change but often the old system is modified to solve these changes. A flexib…

"...it's not the software that rots but instead the users and/or organization that decays."

Orgs decay, sure.

But I believe the OC's point was that orgs become more brittle over time as they specialize. Conway's Law would suggest that software architecture mirrors org structure, so it too would become more brittle.

Applicable cliches: "victim of one's own success", "the complexity catastrophe".

Going the full meta here, I'm okay with the death-rebirth cycle for orgs. Yes, a lot of knowledge (experience) is lost. But forgetfulness is also crucial for learning, adaptation.

Re: Why Does Software Rot?

#68

Post by bernardlunn »

brownbat wrote: post #38

Note, article is not talking about bit rot, I think that's confusing a lot of people. The point might be clearer as: "Adaptability and efficiency are opposing priorities." Ecosystems face this too. A stable environment will lead to adaptations that improve efficiency, while creating new dependencies on everything staying the same. In a sense, species are constantly competing to make the ecosystem more fragile. If thi…

"Adaptability and efficiency are opposing priorities." Great summary. Means I don't need to reach the OP

Re: Why Does Software Rot?

#69

Post by nickpsecurity »

specialist wrote: post #67
fallous wrote: post #40

In most of the cases discussed in the article, it's not the software that rots but instead the users and/or organization that decays. When a system is created, it is generally designed to solve a known set of problems encountered by an existing population of users. Over time, the tool creators, original users, and the current problem domains change but often the old system is modified to solve these changes. A flexib…

"...it's not the software that rots but instead the users and/or organization that decays." Orgs decay, sure. But I believe the OC's point was that orgs become more brittle over time as they specialize. Conway's Law would suggest that software architecture mirrors org structure, so it too would become more brittle. Applicable cliches: "victim of one's own success", "the complexity catastrophe". Going the full meta he…

It was nice up to this: "But forgetfulness is also crucial for learning, adaptation."

In IT, it's the opposite: history repeats itself endlessly with same flaws, same missed opportunities, and same techniques recreated due to often-willful ignorance of the past. One of the things I do here is get old or even current work to people it might benefit. The number of times the old stuff applies to current problems, but was never handed down to those people by predecessors, shows the problem we need to work on is maintaining, packaging, and delivering prior wisdom. Interestingly, the other engineering disciplines already do that a lot better with IT remaining pretty stubborn. To put loss into perspective, it took some groups 50+ years to reinvent benefits of Burroughs B5000 and ALGOL. Just one example among many.

Re: Why Does Software Rot?

#70

Post by SilasX »

brownbat wrote: post #38

Note, article is not talking about bit rot, I think that's confusing a lot of people. The point might be clearer as: "Adaptability and efficiency are opposing priorities." Ecosystems face this too. A stable environment will lead to adaptations that improve efficiency, while creating new dependencies on everything staying the same. In a sense, species are constantly competing to make the ecosystem more fragile. If thi…

There's a similar relationship between "regularity/predictability of an environment" and "how much optimization is possible".
Post reply on HN