Live data from Hacker News

Why Does Software Rot?

overcomingbias.com

71–80 of 81 posts

Re: Why Does Software Rot?

#71

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…

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

As jussaskin said, it can happen to them too. For example, VM/370 was among first virtualization schemes that could do all kinds of things PC/server virtualization bragged on later. Many key apps/OS's might be put in it. Yet, you'd be hard-pressed to run one of those with today's IT budgets if you couldn't afford a mainframe. Likewise, quite a lot of PC virtualization vendors came and went. The survivors occasionally have compatibility issues or corporations start going in different directions with less support of the older product. The product itself is often tied to a specific OS or HW combination that might go away.

One can use virtualization to help future-proof apps. IBM's System/38 (later AS/400, iSeries, and IBM i) did this for decades. However, to be fully future-proof (esp for vendor level), the virtualization SW/HW solution itself needs to be immune to the problem. That means legally, easily-cloned HW with same for software and virtualization layer. Closest thing maybe NOVA microhypervisor on Loongson-style OSS CPU with x86 emulation if it's x86 apps. RISC-V w/ virtualization support otherwise.

Guess what future-proof virtualization all the mainstream approaches aren't using, though? ;)

Re: Why Does Software Rot?

#72

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…

I think the big question with the storage space we've come into is... why don't we have all the toolchains/environments available? Why isn't having multiple versions of every dependency just part of how we do things now?

Re: Why Does Software Rot?

#73
post #70

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".

Not sure which way you say the relationship goes.

My first guess would be that the more regular/predictable an environment is, the more optimizations are possible.

Re: Why Does Software Rot?

#74

Earlier quoted context omitted.

"...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 wa…

I agree with you.

By "forgetfulness", I also mean the stubborn clinging to the old ways, because reasons. The necessary dying of the old guard, a la Kuhn's Structure of Scientific Revolutions.

But I also mean that each new cohort apparently needs to rediscover the deep truths (first principles) for themselves, to earn the wisdom vs blindly accepting received knowledge. I have no idea why this seems to be the case.

  When I was a boy of fourteen, my father was so ignorant I could 
  hardly stand to have the old man around. But when I got to be 
  twenty-one, I was astonished at how much the old man had learned 
  in seven years.

    -- Mark Twain (disputed)
Perhaps forgetfulness is the wrong word. I'd don't yet have another. Some trite phrase for the culling of the herd, gouging out the dryrot, burning off the grasslands, aggressive RIFFing of the tentured... That also conveys that we must give people the room and opportunity to learn things for themselves.

Maybe what I'm advocating is the Socratic Method. Versus telling people "just because".

Thank you.

Re: Why Does Software Rot?

#75
post #63

Earlier quoted context omitted.

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 d…

strncpy is strcpy's daft cousin that wastefully writes extra null characters---except when there is no room; then it neglects to null-terminate at all.

strncpy was not needed even in C90, because of sprintf, which is less clumsy to use, doing everything in one step:

  char array[64];
  sprintf(array, "%.63s", some_string);
If we replace the 63 with * , we can pass a dynamic size:

  sprintf(array, "%.*s", (int) sizeof array - 1, some_string);

Re: Why Does Software Rot?

#76

Earlier quoted context omitted.

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 wa…

I agree with you. By "forgetfulness", I also mean the stubborn clinging to the old ways, because reasons. The necessary dying of the old guard, a la Kuhn's Structure of Scientific Revolutions. But I also mean that each new cohort apparently needs to rediscover the deep truths (first principles) for themselves, to earn the wisdom vs blindly accepting received knowledge. I have no idea why this seems to be the case. Wh…

"By "forgetfulness", I also mean the stubborn clinging to the old ways, because reasons. The necessary dying of the old guard, a la Kuhn's Structure of Scientific Revolutions."

Well, that's true. I think we might need to distinguish between what ideas are lost or are not what a new group is clinging to. Often comes with new people, young or old, coming into an organization. Maybe also distinguish between "current thoughts on what's best method" vs "known methods along with their benefits and problems."

"Maybe what I'm advocating is the Socratic Method. Versus telling people "just because"."

Well, there's how we publish the knowledge and how they learn it. I'm for traditional reporting with empirical focus, less silos, easier search, and easier distribution. Far as learning, Socratic Method is one among many methods that might have potential. It's too big a topic for me outside brief work I did on using various parts of brain simultaneously to increase recall, incremental problem solving of increasing complexity, matching training to realistic scenarios, and side-projects that are open-ended to match fun & curiosity. Don't think I did anything else in research on the topic. Well, a M.C. test generator and some expert system prototypes but they were crap honestly. :)

Re: Why Does Software Rot?

#77
post #70

Earlier quoted context omitted.

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

Not sure which way you say the relationship goes. My first guess would be that the more regular/predictable an environment is, the more optimizations are possible.

That's correct. Optimization isn't really possible in a "white noise universe".

The less regular the universe is, the more general and less specialized your solution can be.

Re: Why Does Software Rot?

#78
There is an analogy to be drawn between software and societies, and they way their early adaptations to one environment block their later adaptions to another.

Re: Why Does Software Rot?

#79

Earlier quoted context omitted.

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…

semi-related: a couple months ago I found a large industrial shipping scale in my parents basement. I grabbed an FTDI USB -> RS232 cable and a DB25 -> DB9 cable, plugged it into a Raspberry Pi, and hacked this together: https://gist.github.com/sielickin/8cc79f0cb6a4b4c229b9786dff... There are some nasty hacks in there and probably a few bugs that I could fix up at some point, but it works just fine! I love how in a l…

s/http page/html page/

Re: Why Does Software Rot?

#80

An interesting simile here is that software rots in the same way that Encyclopedias do. (This is admittedly a fitting simile partly because the simile itself is being rotted by software like Wikipedia.) In the world where new Encyclopedias (and Almanacs and Recipe Books) were printed and sold on an annual basis, the question was often why do we need "this year's Encyclopedia" when the old one is still perfectly valid…

It's a nice analogy but there are important differences here. The thing is that the process of encyclopedias roting/going-out-of-date is obvious because we understand that an encyclopedia is a collection of assertions about the world. It is not as obvious that software is also a set of assertions about the world - and it's not as easy to determine which assertions about the world the software depends on. Just as much…

Thanks Joe. I think the difference you point out only strengthen analogy, and which I tried to colorfully explore in the original post, but expand here because it is interesting.

«It is not as obvious that software is also a set of assertions about the world - and it's not as easy to determine which assertions about the world the software depends on.»

I like that definition: "Software is a set of assertions about the world". It may be less obvious than an Encyclopedia, but again, perhaps that only makes it a better analogy.

«An encyclopedia is a static list of supposed facts and its change is somewhat predictable by in terms of how our understanding of the world changes.»

Ah. This is where Wikipedia actually strengthens the analogy. An Encyclopedia has always been loosely hyperlinked with cross-references. Entire complex webs of assumptions and assertions about the state of the world. Refactors of Encyclopedia content always could have interesting complex relationships with other content.

Certainly there is an extent to which Encyclopedias are known to predictably change: new elected officials each cycle, for example. But there is still plenty of unpredictable changes: new red letter days in history, new evolutionary scientific shifts in consensus, new lenses in which a culture views itself.

An example of the lattermost, in that yellowed 70s Encyclopedia you could still spot fragments in the process of being excised of what we now consider to be racist views of culture and cultural history. That among other things was a source of fascination to this teen in the 90s.

The often unspoken truth is that as much as Encyclopedias try very hard to be objective, they are still a product of their culture. (So too do we often want to think that Software is objective and nothing but mathematical assertions about facts about our world, but here too they are products of our [corporate] cultures and moored in ways both obvious and not obvious to the culture that built them.)

Wikipedia shows us that complexity of Encyclopedias much more directly, but those bones were always there in Encyclopedias even when we couldn't see them. A link to click is much faster than shuffling between volumes of an encyclopedia to follow cross-references, but the cross-references have always been necessary to build up a view of the assertions about the world.

More interestingly, Wikipedia strives to give a better, more transparent view, into the cultural biases of its contents; all of the [citation needed] tags and "More Research Required" templates and Talk pages of endless discussion. The novelty here is that they've opened up all of that to the common user, but the essence of that has always been in Encyclopedias, just locked away by the librarians and researchers in their own notes.

Post reply on HN