5 ms·

I think what's discussed in OP is not software rot, but software clutter. Software rot would be something inherent that happens to software naturally over time,

by euske 8y ago

I think what's discussed in OP is not software rot, but software clutter. Software rot would be something inherent that happens to software naturally over time, without any external change. I can't think of a good example of this, so I think software rot is in general a misnomer.

overshard 8y ago
I'm not sure software clutter describes this either but I understand what you are trying to say. I think of software rot more as code that hasn't been touched by anyone in years and now it no longer works due to it's environment changing. Things like API updates, general system updates, security updates or other factors causing it to malfunction eventually. I had a thumbnailing micro service I made years ago that worked happily until 3 months ago. A combination of PIL updates and various Ubuntu security updates made it no longer work properly in various ways from keeping the alpha layer on PNG files to cropping from the wrong position. I consider this software rot since I hadn't updated anything but the surrounding system.
- rgoulter 8y ago
  An even more extreme case of this is trying to bootstrap a compiler from the first version, e.g.: http://www.joachim-breitner.de/blog/748-Thoughts_on_bootstrapping_GHC http://www.joachim-breitner.de/blog/748-Thoughts_on_bootstra... """So it seems that besides GHC, only ever HBC was used to compiler GHC. HBC is a Haskell compiler where we find the sources of one random version only thanks to archive.org. Parts of it are written in C, so I looked into this: Compile HBC, use it to compile GHC-0.29, and then step for step build every (major) version of GHC until today. .... [M]ost of [HBC] is written in LML, and the LML compiler is written in LML."""
deleted 8y ago
[deleted]
phkahler 8y ago
Well there is bit-rot. One manifestation of this is when nobody works on code for a while and it becomes unusable or less usable because the world has moved on. Maybe newer versions of the compiler won't compile it. Maybe some of the dependencies have changed. Just try to build even a small program written for Windows 95 or 98 today. This is one reason "do one thing and do it well" is useful. The interface is kept simple and should be easy enough to update to a new environment. At the same time, that means for bigger systems a lot of small things will need updating over time, but at least the changes should be straight forward.
- badsectoracula 8y ago
  > Just try to build even a small program written for Windows 95 or 98 today. This largely works, especially on the C/C++ side.
  - asveikau 8y ago
    My experience is not really. The most common thing you will need to fix is assumptions about pointer sizes. Including casts between integer and pointer, which compilers used to be more permissive about in the days before intptr_t. (A few years ago I was compiling code from the 90s that did these casts implicitly, which had me wondering why the compiler ever let them get away with it...) C++ in particular has also changed a lot since the 90s including how permissive the compilers used to be, even for stuff covered by c++98.
- agumonkey 8y ago
  isnt this 'bitrot' function of the interface size ? I doubt sed will ever rot for instance
  - teddyh 8y ago
    sed does simple operations on text. But it certainly had to change when the definition of “text” changed from US-ASCII to “Whatever the LOCALE settings are, but most often ISO-8859-1”, and then later to “Most often UTF-8”.
    - agumonkey 8y ago
      damn humans
  - abbeyj 8y ago
    I think we can test this retroactively. sed has been around a long time. So we can go grab a copy from, say, Version 7 Unix and try to build it on a modern system. I grabbed v7.tar.gz from https://github.com/v7unix/v7unix https://github.com/v7unix/v7unix, extracted it, and tried to build: $ make cc -n -O -c -o sed0.o sed0.c In file included from sed0.c:2: sed.h:116: warning: declaration does not declare anything sed.h:128: warning: declaration does not declare anything sed0.c: In function ‘main’: sed0.c:32: error: ‘union reptr’ has no member named ‘ad1’ sed0.c:48: warning: incompatible implicit declaration of built-in function ‘exit’ <snip many more lines> The problem here is that although sed was written in "C" and we have a "C compiler" on our system, the definition of what exactly constitutes "C" has changed. The modern compiler no longer accepts the same language as the V7 compiler. We can fix the source to deal with this and produce a working binary. But then, what would we do with it? We can't really install it as /bin/sed. The world now expects /bin/sed to support switches and syntax that this sed does not. Trying to use this as /bin/sed would cause lots of programs to fail. The definition of what exactly constitutes a working "sed" program has also changed. So it seems to me like sed already has rotted in some sense. Looking forward, the sed from a current system is likely to be similarly rotted when you try to use it on a machine 40 years from now.
fredsted 8y ago
Think about freshness. When code was recently written, it's fresh in memory. People can remember what the code was written for, and why it was written. As time passes, code gets stale. And finally, when people can't remember what the code does, at that point you could consider it rotten. At some point the tooling becomes unavailable and you wont be able to run it! Ways to prevent code rot: * Clean (refactor, remove tech debt and legacy code) often. * Write good comments. * Keep tooling & dependencies up to date.
Angostura 8y ago
In my opinion, software "rot" is most likely where software has been passed on through a number of lead contributors over time. The original reasons for a particular set of design decisions are forgotten. Someone else comes along and doesn't quite understand a particular nuance, tries to add factionality, but it doesn't quite work, so writes a bit of code that ends up reimplementing an aspect of the original, so you have two lots of code doing the same thoing in different ways, perhaps with their own set of variables. Then someone else comes along and is faced with real confusion and before you know it you find yourself with a system which, if you update data one way, the changes are sometimes picked up by another part of the system, sometimes not and... its rotten.

by euske 8y ago

overshard 8y ago

I'm not sure software clutter describes this either but I understand what you are trying to say. I think of software rot more as code that hasn't been touched by anyone in years and now it no longer works due to it's environment changing. Things like API updates, general system updates, security updates or other factors causing it to malfunction eventually. I had a thumbnailing micro service I made years ago that worked happily until 3 months ago. A combination of PIL updates and various Ubuntu security updates made it no longer work properly in various ways from keeping the alpha layer on PNG files to cropping from the wrong position. I consider this software rot since I hadn't updated anything but the surrounding system.

rgoulter 8y ago
An even more extreme case of this is trying to bootstrap a compiler from the first version, e.g.: http://www.joachim-breitner.de/blog/748-Thoughts_on_bootstrapping_GHC http://www.joachim-breitner.de/blog/748-Thoughts_on_bootstra... """So it seems that besides GHC, only ever HBC was used to compiler GHC. HBC is a Haskell compiler where we find the sources of one random version only thanks to archive.org. Parts of it are written in C, so I looked into this: Compile HBC, use it to compile GHC-0.29, and then step for step build every (major) version of GHC until today. .... [M]ost of [HBC] is written in LML, and the LML compiler is written in LML."""

deleted 8y ago

[deleted]

phkahler 8y ago

Well there is bit-rot. One manifestation of this is when nobody works on code for a while and it becomes unusable or less usable because the world has moved on. Maybe newer versions of the compiler won't compile it. Maybe some of the dependencies have changed. Just try to build even a small program written for Windows 95 or 98 today. This is one reason "do one thing and do it well" is useful. The interface is kept simple and should be easy enough to update to a new environment. At the same time, that means for bigger systems a lot of small things will need updating over time, but at least the changes should be straight forward.

badsectoracula 8y ago
> Just try to build even a small program written for Windows 95 or 98 today. This largely works, especially on the C/C++ side.
- asveikau 8y ago
  My experience is not really. The most common thing you will need to fix is assumptions about pointer sizes. Including casts between integer and pointer, which compilers used to be more permissive about in the days before intptr_t. (A few years ago I was compiling code from the 90s that did these casts implicitly, which had me wondering why the compiler ever let them get away with it...) C++ in particular has also changed a lot since the 90s including how permissive the compilers used to be, even for stuff covered by c++98.
agumonkey 8y ago
isnt this 'bitrot' function of the interface size ? I doubt sed will ever rot for instance
- teddyh 8y ago
  sed does simple operations on text. But it certainly had to change when the definition of “text” changed from US-ASCII to “Whatever the LOCALE settings are, but most often ISO-8859-1”, and then later to “Most often UTF-8”.
  - agumonkey 8y ago
    damn humans
- abbeyj 8y ago
  I think we can test this retroactively. sed has been around a long time. So we can go grab a copy from, say, Version 7 Unix and try to build it on a modern system. I grabbed v7.tar.gz from https://github.com/v7unix/v7unix https://github.com/v7unix/v7unix, extracted it, and tried to build: $ make cc -n -O -c -o sed0.o sed0.c In file included from sed0.c:2: sed.h:116: warning: declaration does not declare anything sed.h:128: warning: declaration does not declare anything sed0.c: In function ‘main’: sed0.c:32: error: ‘union reptr’ has no member named ‘ad1’ sed0.c:48: warning: incompatible implicit declaration of built-in function ‘exit’ <snip many more lines> The problem here is that although sed was written in "C" and we have a "C compiler" on our system, the definition of what exactly constitutes "C" has changed. The modern compiler no longer accepts the same language as the V7 compiler. We can fix the source to deal with this and produce a working binary. But then, what would we do with it? We can't really install it as /bin/sed. The world now expects /bin/sed to support switches and syntax that this sed does not. Trying to use this as /bin/sed would cause lots of programs to fail. The definition of what exactly constitutes a working "sed" program has also changed. So it seems to me like sed already has rotted in some sense. Looking forward, the sed from a current system is likely to be similarly rotted when you try to use it on a machine 40 years from now.

fredsted 8y ago

Think about freshness. When code was recently written, it's fresh in memory. People can remember what the code was written for, and why it was written. As time passes, code gets stale. And finally, when people can't remember what the code does, at that point you could consider it rotten. At some point the tooling becomes unavailable and you wont be able to run it! Ways to prevent code rot: * Clean (refactor, remove tech debt and legacy code) often. * Write good comments. * Keep tooling & dependencies up to date.

Angostura 8y ago

In my opinion, software "rot" is most likely where software has been passed on through a number of lead contributors over time. The original reasons for a particular set of design decisions are forgotten. Someone else comes along and doesn't quite understand a particular nuance, tries to add factionality, but it doesn't quite work, so writes a bit of code that ends up reimplementing an aspect of the original, so you have two lots of code doing the same thoing in different ways, perhaps with their own set of variables. Then someone else comes along and is faced with real confusion and before you know it you find yourself with a system which, if you update data one way, the changes are sometimes picked up by another part of the system, sometimes not and... its rotten.