10 ms·

Why Does Software Rot?

96 points by nhaliday 10y ago

ensiferum 10y ago
Wheres the connection to software rot?
carsongross 10y ago
What does rot even mean, in terms of software? As far as I can tell, he means "Why is complex software hard to change" which is a reasonable, though fairly easy to answer, question. Software doesn't rot. New features or refactors screw it up. New needs or technologies may make it obsolete. But it doesn't rot, and people who talk that way are often busy-body rewriters who want to pitch the existing implementations, with all their Chesterton Fences[1], and begin anew. [1] http://www.chesterton.org/taking-a-fence-down/ http://www.chesterton.org/taking-a-fence-down/
- nbouscal 10y ago
  It rots in the sense that it becomes harder to change (or fix) over time, even if the code stays the same. This happens via loss of institutional knowledge as people forget how it works, loss of knowledge of the technologies used as they're replaced, etc. It's not just the complexity. Old code is usually harder to change than new code, even if they're equally complex.
  - carsongross 10y ago
    That isn't rot. The metaphor doesn't make any sense. Software literally does not change. Except for the occasional cosmic ray, I can think of few things less appropriate to apply the term "rot" to.
    - jussaskin 10y ago
      Software doesn't exist in isolation. It interacts with its host OS, shared libraries, other programs, protocols, file formats and external systems. If it can't keep up then it effectively rots even though not a single byte of it has changed.
    - beat 10y ago
      It's a metaphor, not an equivalence. It doesn't even have to be in the same field, as long as the meaning is conveyed. Bit rot is an excellent metaphor, even though it's nothing like physical rot if you get pedantic about it.
    - nbouscal 10y ago
      You're the first person I've heard say that the metaphor doesn't make any sense; meanwhile, a lot of people regularly use it, which implies that it makes sense to them. You're welcome to not like the metaphor, but you don't really get to declare that it's objectively wrong… it's a metaphor.
- cbd1984 10y ago
  Changes in the environment screw it up, too. As an obvious case, if your software is screen-scraping a website and the website's layout changes, your software's just rotted even though your code hasn't changed one bit. Another example is software which interfaces with hardware: Swapping one specific piece of hardware out for "the same" hardware made by a different manufacturer can cause rot, because "the same" hardware isn't necessarily the same in every respect. If your software tickles it the right way, it can expose differences which can cause your software to fail in new and exciting ways. Nothing changed, yet everything's different. As you expand the universe of things your code has to interact with, this kind of change becomes inevitable. As always, the more points of attachment, the more potential for future pain.
- ourmandave 10y ago
  The American Chesterton Society logo had to be the inspiration for Buzz Killington. http://familyguy.wikia.com/wiki/Buzz_Killington http://familyguy.wikia.com/wiki/Buzz_Killington
- wvenable 10y ago
  > Software doesn't rot. On the face it, that's true. But the reality is that the environment that software runs in is constantly evolving and software that doesn't also change slowly starts working worse until it stops working entirely. We have plenty of software at my work that hasn't changed fundamentally in 10 years and can no longer be used. Lots of really old software requires equally unchanged old environments and old hardware and that hardware slowly rots too.
  - johannes1234321 10y ago
    ... add to this that user expectations change. Applications not matching that feel rotted. Just look at websites from 10 years back to get an idea only on very surface levels.
- akkartik 10y ago
  I think you're taking the phrasing too literally. When we say software rots, we're not just talking about the bits that make up a program, but also its interface with its environment, and the knowledge about it in people's brains. Both those connections are indeed subject to drift/evaporation/entropy. The two failure modes you mentioned are symptoms of that underlying evaporation. I spend a lot of time thinking about this (http://akkartik.name/about http://akkartik.name/about), but lately I try to steer clear of metaphors, because they're so often clear in my mind but utterly opaque to someone else's. So, I don't care what we call it, as long as more people try to fix the problem.
lifeisstillgood 10y ago
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 center and the timeouts kill the jobs etc. It looks rotten. "Rot" more accurately is just not keeping the code inside the code base up with entropy outside the code base
- cpeterso 10y ago
  Or when the operating system or build tools change or are no longer available. Your code hasn't changed and suddenly it no longer compiles.
- akkartik 10y ago
  Your reasons are very similar to mine: http://akkartik.name/about http://akkartik.name/about. A. Backwards compatibility considerations. B. Churn in personnel. C. Vestigial features. Awesome! Comparing the two, I merged your 2 and 3 into a single reason, considering both as cases of environmental change. In its place I have a new one: changing personnel causing evaporation in system knowledge. Did you consider this? Now I think about it, maybe it overlaps with your 1 (my C). So the final mapping is perhaps: 1 <-> B, C 2, 3 <-> A
- mamon 10y ago
  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"
jussaskin 10y ago
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 latest releases of the tools then it's already got one foot in the grave.
- ArkyBeagle 10y ago
  Through the miracle of virtual machines, this is much less so. VMs are the NAT of computer systems.
  - jussaskin 10y ago
    Less so, I agree. But give it time - older VM image and container formats will probably rot as well.
    - smilekzs 10y ago
      VM formats are easier to migrate than the actual software they run. On the other hand this is a valid concern for containers.
    - specialist 10y ago
      Extending the digital entropy analogy: decay rate, half-lives.
  - jussaskin 10y ago
    Even though the VM image and tooling may still be runnable, the world around it with which it must interact continues to evolve and can leave your software obsolete.
    - ArkyBeagle 10y ago
      One for one thing, another for another.
boznz 10y ago
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 interfaced to a piece of hardware on the parallel port and the parallel port and the manufacturer went the way of the dodo. I have seen a stand-alone DOS 6 program running a machine at a factory. The PC has been replaced three times now is only a few years old but the operator says it still does the job, I also have a 8051 powered clock I built in 1987 that still happily ticks along if I plug it in.
- ArkyBeagle 10y ago
  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 proportionally, it's less than all new things on offer. FWIW, if you look carefully there will always be a motherboard available with a working parallel port. They're not cheap, and at some point the thing plugged into that parallel port wears out.
  - Asooka 10y ago
    In a way, isn't this a form of make-work for software engineers? Plus, I'm not sure what is worse - having to remake things every 5 years or so slightly differently, or not having jobs.
    - ArkyBeagle 10y ago
      In a way. It's hard to stay focused; they used to say the ultimate for a CS grad was to write the Great American Compiler ( as for an English major it may have been the Great American Novel ). As per Orwell, the hardest thing anyone does is to see what's right under their nose - to stay focused and commit to the most relevant work.
serge2k 10y ago
> Newer programming languages are often interesting, but they are typically less flexible at first than older languages. Everything else being equal, older languages perform better and are faster At the cost of more difficulty in writing, or other tradeoffs (e.g. security). > Programmers, especially young programmers, often prefer to start from scratch. .. In part because it is much more fun to write code than to read code, while both are equally hard. No way! You need to NPM literally everything.
dcre 10y ago
Software rots because everything does.
jussaskin 10y ago
I find that integrated tests in software projects go a long way to reducing rot. When something eventually invariably breaks due to some external factor, the test suite greatly reduces the time to identify and fix the problem.
- narrator 10y ago
  If you can build a piece of software and run unit and integration tests on it, it is more or less rot proof. That's because all those tests lets one delete or replace components of the system without having to worry too much that the whole thing is going to break in some unknown way that won't be caught until it's in production. Without a good suite, the larger the system gets, the more people get scared of doing radical things to it because they are worried about breaking some critical functionality. As far as the not being able to build aspect goes, the main threat here is relying to much on closed source software and/or libraries that go out of support that no one can find the license, or critical documentation for, or worse manifests some critical unfixable bug.
- samsonasu 10y ago
  Id love to agree with this but my experience differs on modern stacks. We so often mock or stub APIs, use a web driver that's pinned to a certain version of WebKit, test against virtual dom, etc that it's hard to get real reliable test results that don't break all the time. But I suppose that's the problem; we don't have the time to fix bugs related to the environment that crop up when no code changes so we insulate our tests from the environment by design.
WorldMaker 10y ago
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. Books in general decay pretty slowly and have a long shelf life, but the facts and the views in the world inside them are frozen and possibly. Changes from year to year of an Encyclopedia are somewhat hard to notice, but in Middle School in the 90s I recall having to compare articles from a tobacco yellowed Encyclopedia set from the 70s to trips to the same articles from very early predecessors of Wikipedia. The worlds contained in those two sorts of Encyclopedias were very interestingly diverging. The yellowed Encyclopedia's facts were almost all still valid and "worked", but there were things that didn't hold up and lots of new facts that needed to be inserted in various places. If I were to edit an Encyclopedia, I'm not sure I would start from the version in that yellowed Encyclopedia if I could find a more recent set. Some of the predecessors to Wikipedia were direct descendants of that yellowed Encyclopedia and yet for various reasons historical and technical, Wikipedia itself did not inherit directly from that set in any meaningful way. (It's interesting to note too that the physical media of software to date has a much shorter shelf life than the pulp medium of books, tobacco-smoke-filled library aging included, so argument exists that software rots worse than Encyclopedias physically, at least.)
- joe_the_user 10y ago
  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, 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. We have some idea what will be valid or invalid in an encyclopedia X years old. Software depends on obscure facts about OSes, about networks, about UI expectations, about time, and so-forth and moreover, software involves chains of dependencies so it's harder to predict what would or wouldn't break software X years old.
brownbat 10y ago
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 this holds, there are broad impacts to information systems outside of software. broader impact of this. We like to fantasize about the mind being immortal. Maybe we could fix the telemere thing, figure out cancer, hop our brain to a clone, or upload our consciousness to some cloud. But in my experience, being mentally alive involves some mix of plasticity and progressive refinement. You can't have both forever.
- bernardlunn 10y ago
  "Adaptability and efficiency are opposing priorities." Great summary. Means I don't need to reach the OP
- SilasX 10y ago
  There's a similar relationship between "regularity/predictability of an environment" and "how much optimization is possible".
  - TeMPOraL 10y ago
    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.
    - SilasX 10y ago
      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.
fallous 10y ago
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 flexible system may be adaptable to certain amounts of change, but only if the current populace of creators/maintainers as well as users understand the limits. If they do not, the software often ends up less useful than if it had never been touched.
- specialist 10y ago
  "...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.
  - nickpsecurity 10y ago
    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.
    - 10y ago
notacoward 10y ago
I think rot is not quite the correct metaphor. In my experience it's more likely to ossify, become sclerotic, build up scar tissue. As features are added or performance is tweaked, individual pieces become more complex and the connections between them multiply. If specific action (refactoring) isn't taken to fight this tendency, later developers will react to one piece being maintainable by making even more spurious connections and workarounds in adjacent pieces. That fixes the immediate problem, but makes things worse overall in the long term. Ultimately everything turns into the kind of tangled mess that everyone who has worked on an old multi-person project can recognize. Unfortunately, a good refactoring requires understanding greater than the original author's[1], and therein lies another whole essay. ;) [1] Related to http://www.linusakesson.net/programming/kernighans-lever/ http://www.linusakesson.net/programming/kernighans-lever/
Spooky23 10y ago
Dependencies. Big old hairy mainframe apps have no dependencies, and last decades. Anything new expects constant updating.
hermanradtke 10y ago
> Apache, the most important web server software today, is an old piece of technology whose name is a play on words (“a patched server”) indicating that it has been massively patched. Is this true? I have never heard that Apache was a play on of words.
- kazagistar 10y ago
  Apparently its a myth, and the original intention was based on the name of the tribe. http://www.linux-mag.com/id/472/ http://www.linux-mag.com/id/472/
textmode 10y ago
"... the arrogance and self-indulgence of youth." s/youth/younger programmers/ How can they make work for themselves? 1. Do what's already been done, not even knowing it's already been done. 2. Declare "rot" or some similar claim of obsolescence and proceed to redo what's already been done. There's nothing necessarily awful about this unless they fail to do a better job than the earlier effort. Alas, this is too often the case. For a variety of reasons. In the early days, portability was a higher priority. Not to mention longevity. Because everything was expensive. Today's software "rots" a lot faster than the software from the early days of computing, IMO. And so the younger programmers have lots of "work" to do. Yet I do not see much progress being made. Because I do not measure progress by productivity alone. Programmers who can churn out code in a dozen different languages to do the same old things are a dime a dozen. As a user, I do not want software that needs to be updated every week. Poorly written software and gratuitous use of network bandwidth. But I can see how programmers who love writing code would enjoy this state of affairs.
- simula67 10y ago
  Replace younger programmers with older programmers and people would scream ageism.
jaytaylor 10y ago
"Software rot" stems from the world around the software changing in a way the software is unable to adapt to, and breaking it.
- bloaf 10y ago
  I feel like "rot" is the wrong term, and the right term might come from that old parable about the man who built his house on the sand rather than the rock.
tacos 10y ago
Stewart Brand wrote a book called "How Buildings Learn" and in many ways it's a better version of this post. https://en.wikipedia.org/wiki/Shearing_layers https://en.wikipedia.org/wiki/Shearing_layers
vonnik 10y ago
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.

96 points by nhaliday 10y ago

Wheres the connection to software rot?

What does rot even mean, in terms of software? As far as I can tell, he means "Why is complex software hard to change" which is a reasonable, though fairly easy to answer, question. Software doesn't rot. New features or refactors screw it up. New needs or technologies may make it obsolete. But it doesn't rot, and people who talk that way are often busy-body rewriters who want to pitch the existing implementations, with all their Chesterton Fences[1], and begin anew. [1] http://www.chesterton.org/taking-a-fence-down/ http://www.chesterton.org/taking-a-fence-down/

nbouscal 10y ago
It rots in the sense that it becomes harder to change (or fix) over time, even if the code stays the same. This happens via loss of institutional knowledge as people forget how it works, loss of knowledge of the technologies used as they're replaced, etc. It's not just the complexity. Old code is usually harder to change than new code, even if they're equally complex.
- carsongross 10y ago
  That isn't rot. The metaphor doesn't make any sense. Software literally does not change. Except for the occasional cosmic ray, I can think of few things less appropriate to apply the term "rot" to.
  - jussaskin 10y ago
    Software doesn't exist in isolation. It interacts with its host OS, shared libraries, other programs, protocols, file formats and external systems. If it can't keep up then it effectively rots even though not a single byte of it has changed.
  - beat 10y ago
    It's a metaphor, not an equivalence. It doesn't even have to be in the same field, as long as the meaning is conveyed. Bit rot is an excellent metaphor, even though it's nothing like physical rot if you get pedantic about it.
  - nbouscal 10y ago
    You're the first person I've heard say that the metaphor doesn't make any sense; meanwhile, a lot of people regularly use it, which implies that it makes sense to them. You're welcome to not like the metaphor, but you don't really get to declare that it's objectively wrong… it's a metaphor.
cbd1984 10y ago
Changes in the environment screw it up, too. As an obvious case, if your software is screen-scraping a website and the website's layout changes, your software's just rotted even though your code hasn't changed one bit. Another example is software which interfaces with hardware: Swapping one specific piece of hardware out for "the same" hardware made by a different manufacturer can cause rot, because "the same" hardware isn't necessarily the same in every respect. If your software tickles it the right way, it can expose differences which can cause your software to fail in new and exciting ways. Nothing changed, yet everything's different. As you expand the universe of things your code has to interact with, this kind of change becomes inevitable. As always, the more points of attachment, the more potential for future pain.
ourmandave 10y ago
The American Chesterton Society logo had to be the inspiration for Buzz Killington. http://familyguy.wikia.com/wiki/Buzz_Killington http://familyguy.wikia.com/wiki/Buzz_Killington
wvenable 10y ago
> Software doesn't rot. On the face it, that's true. But the reality is that the environment that software runs in is constantly evolving and software that doesn't also change slowly starts working worse until it stops working entirely. We have plenty of software at my work that hasn't changed fundamentally in 10 years and can no longer be used. Lots of really old software requires equally unchanged old environments and old hardware and that hardware slowly rots too.
- johannes1234321 10y ago
  ... add to this that user expectations change. Applications not matching that feel rotted. Just look at websites from 10 years back to get an idea only on very surface levels.
akkartik 10y ago
I think you're taking the phrasing too literally. When we say software rots, we're not just talking about the bits that make up a program, but also its interface with its environment, and the knowledge about it in people's brains. Both those connections are indeed subject to drift/evaporation/entropy. The two failure modes you mentioned are symptoms of that underlying evaporation. I spend a lot of time thinking about this (http://akkartik.name/about http://akkartik.name/about), but lately I try to steer clear of metaphors, because they're so often clear in my mind but utterly opaque to someone else's. So, I don't care what we call it, as long as more people try to fix the problem.

lifeisstillgood 10y ago

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 center and the timeouts kill the jobs etc. It looks rotten. "Rot" more accurately is just not keeping the code inside the code base up with entropy outside the code base

cpeterso 10y ago
Or when the operating system or build tools change or are no longer available. Your code hasn't changed and suddenly it no longer compiles.
akkartik 10y ago
Your reasons are very similar to mine: http://akkartik.name/about http://akkartik.name/about. A. Backwards compatibility considerations. B. Churn in personnel. C. Vestigial features. Awesome! Comparing the two, I merged your 2 and 3 into a single reason, considering both as cases of environmental change. In its place I have a new one: changing personnel causing evaporation in system knowledge. Did you consider this? Now I think about it, maybe it overlaps with your 1 (my C). So the final mapping is perhaps: 1 <-> B, C 2, 3 <-> A
mamon 10y ago
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"

jussaskin 10y ago

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 latest releases of the tools then it's already got one foot in the grave.

ArkyBeagle 10y ago
Through the miracle of virtual machines, this is much less so. VMs are the NAT of computer systems.
- jussaskin 10y ago
  Less so, I agree. But give it time - older VM image and container formats will probably rot as well.
  - smilekzs 10y ago
    VM formats are easier to migrate than the actual software they run. On the other hand this is a valid concern for containers.
  - specialist 10y ago
    Extending the digital entropy analogy: decay rate, half-lives.
- jussaskin 10y ago
  Even though the VM image and tooling may still be runnable, the world around it with which it must interact continues to evolve and can leave your software obsolete.
  - ArkyBeagle 10y ago
    One for one thing, another for another.

boznz 10y ago

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 interfaced to a piece of hardware on the parallel port and the parallel port and the manufacturer went the way of the dodo. I have seen a stand-alone DOS 6 program running a machine at a factory. The PC has been replaced three times now is only a few years old but the operator says it still does the job, I also have a 8051 powered clock I built in 1987 that still happily ticks along if I plug it in.

ArkyBeagle 10y ago
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 proportionally, it's less than all new things on offer. FWIW, if you look carefully there will always be a motherboard available with a working parallel port. They're not cheap, and at some point the thing plugged into that parallel port wears out.
- Asooka 10y ago
  In a way, isn't this a form of make-work for software engineers? Plus, I'm not sure what is worse - having to remake things every 5 years or so slightly differently, or not having jobs.
  - ArkyBeagle 10y ago
    In a way. It's hard to stay focused; they used to say the ultimate for a CS grad was to write the Great American Compiler ( as for an English major it may have been the Great American Novel ). As per Orwell, the hardest thing anyone does is to see what's right under their nose - to stay focused and commit to the most relevant work.

serge2k 10y ago

> Newer programming languages are often interesting, but they are typically less flexible at first than older languages. Everything else being equal, older languages perform better and are faster At the cost of more difficulty in writing, or other tradeoffs (e.g. security). > Programmers, especially young programmers, often prefer to start from scratch. .. In part because it is much more fun to write code than to read code, while both are equally hard. No way! You need to NPM literally everything.

dcre 10y ago

Software rots because everything does.

jussaskin 10y ago

I find that integrated tests in software projects go a long way to reducing rot. When something eventually invariably breaks due to some external factor, the test suite greatly reduces the time to identify and fix the problem.

narrator 10y ago
If you can build a piece of software and run unit and integration tests on it, it is more or less rot proof. That's because all those tests lets one delete or replace components of the system without having to worry too much that the whole thing is going to break in some unknown way that won't be caught until it's in production. Without a good suite, the larger the system gets, the more people get scared of doing radical things to it because they are worried about breaking some critical functionality. As far as the not being able to build aspect goes, the main threat here is relying to much on closed source software and/or libraries that go out of support that no one can find the license, or critical documentation for, or worse manifests some critical unfixable bug.
samsonasu 10y ago
Id love to agree with this but my experience differs on modern stacks. We so often mock or stub APIs, use a web driver that's pinned to a certain version of WebKit, test against virtual dom, etc that it's hard to get real reliable test results that don't break all the time. But I suppose that's the problem; we don't have the time to fix bugs related to the environment that crop up when no code changes so we insulate our tests from the environment by design.

WorldMaker 10y ago

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. Books in general decay pretty slowly and have a long shelf life, but the facts and the views in the world inside them are frozen and possibly. Changes from year to year of an Encyclopedia are somewhat hard to notice, but in Middle School in the 90s I recall having to compare articles from a tobacco yellowed Encyclopedia set from the 70s to trips to the same articles from very early predecessors of Wikipedia. The worlds contained in those two sorts of Encyclopedias were very interestingly diverging. The yellowed Encyclopedia's facts were almost all still valid and "worked", but there were things that didn't hold up and lots of new facts that needed to be inserted in various places. If I were to edit an Encyclopedia, I'm not sure I would start from the version in that yellowed Encyclopedia if I could find a more recent set. Some of the predecessors to Wikipedia were direct descendants of that yellowed Encyclopedia and yet for various reasons historical and technical, Wikipedia itself did not inherit directly from that set in any meaningful way. (It's interesting to note too that the physical media of software to date has a much shorter shelf life than the pulp medium of books, tobacco-smoke-filled library aging included, so argument exists that software rots worse than Encyclopedias physically, at least.)

joe_the_user 10y ago
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, 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. We have some idea what will be valid or invalid in an encyclopedia X years old. Software depends on obscure facts about OSes, about networks, about UI expectations, about time, and so-forth and moreover, software involves chains of dependencies so it's harder to predict what would or wouldn't break software X years old.

brownbat 10y ago

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 this holds, there are broad impacts to information systems outside of software. broader impact of this. We like to fantasize about the mind being immortal. Maybe we could fix the telemere thing, figure out cancer, hop our brain to a clone, or upload our consciousness to some cloud. But in my experience, being mentally alive involves some mix of plasticity and progressive refinement. You can't have both forever.

bernardlunn 10y ago
"Adaptability and efficiency are opposing priorities." Great summary. Means I don't need to reach the OP
SilasX 10y ago
There's a similar relationship between "regularity/predictability of an environment" and "how much optimization is possible".
- TeMPOraL 10y ago
  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.
  - SilasX 10y ago
    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.

fallous 10y ago

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 flexible system may be adaptable to certain amounts of change, but only if the current populace of creators/maintainers as well as users understand the limits. If they do not, the software often ends up less useful than if it had never been touched.

specialist 10y ago
"...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.
- nickpsecurity 10y ago
  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.
  - 10y ago

notacoward 10y ago

I think rot is not quite the correct metaphor. In my experience it's more likely to ossify, become sclerotic, build up scar tissue. As features are added or performance is tweaked, individual pieces become more complex and the connections between them multiply. If specific action (refactoring) isn't taken to fight this tendency, later developers will react to one piece being maintainable by making even more spurious connections and workarounds in adjacent pieces. That fixes the immediate problem, but makes things worse overall in the long term. Ultimately everything turns into the kind of tangled mess that everyone who has worked on an old multi-person project can recognize. Unfortunately, a good refactoring requires understanding greater than the original author's[1], and therein lies another whole essay. ;) [1] Related to http://www.linusakesson.net/programming/kernighans-lever/ http://www.linusakesson.net/programming/kernighans-lever/

Spooky23 10y ago

Dependencies. Big old hairy mainframe apps have no dependencies, and last decades. Anything new expects constant updating.

hermanradtke 10y ago

> Apache, the most important web server software today, is an old piece of technology whose name is a play on words (“a patched server”) indicating that it has been massively patched. Is this true? I have never heard that Apache was a play on of words.

kazagistar 10y ago
Apparently its a myth, and the original intention was based on the name of the tribe. http://www.linux-mag.com/id/472/ http://www.linux-mag.com/id/472/

textmode 10y ago

"... the arrogance and self-indulgence of youth." s/youth/younger programmers/ How can they make work for themselves? 1. Do what's already been done, not even knowing it's already been done. 2. Declare "rot" or some similar claim of obsolescence and proceed to redo what's already been done. There's nothing necessarily awful about this unless they fail to do a better job than the earlier effort. Alas, this is too often the case. For a variety of reasons. In the early days, portability was a higher priority. Not to mention longevity. Because everything was expensive. Today's software "rots" a lot faster than the software from the early days of computing, IMO. And so the younger programmers have lots of "work" to do. Yet I do not see much progress being made. Because I do not measure progress by productivity alone. Programmers who can churn out code in a dozen different languages to do the same old things are a dime a dozen. As a user, I do not want software that needs to be updated every week. Poorly written software and gratuitous use of network bandwidth. But I can see how programmers who love writing code would enjoy this state of affairs.

simula67 10y ago
Replace younger programmers with older programmers and people would scream ageism.

jaytaylor 10y ago

"Software rot" stems from the world around the software changing in a way the software is unable to adapt to, and breaking it.

bloaf 10y ago
I feel like "rot" is the wrong term, and the right term might come from that old parable about the man who built his house on the sand rather than the rock.

tacos 10y ago

Stewart Brand wrote a book called "How Buildings Learn" and in many ways it's a better version of this post. https://en.wikipedia.org/wiki/Shearing_layers https://en.wikipedia.org/wiki/Shearing_layers

vonnik 10y ago

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.