9 ms·

Software Rot (2017)

119 points by lelf 8y ago

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”.
- 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.
jeletonskelly 8y ago
I thought we called it "bit rot"
- overshard 8y ago
  "Software rot, also known as code rot, bit rot, software erosion, software decay or software entropy..." https://en.wikipedia.org/wiki/Software_rot https://en.wikipedia.org/wiki/Software_rot
- lioeters 8y ago
  In my mind, I think of "bit rot" more on the storage level, like hard drives with physically corrupted bits.
jakelazaroff 8y ago
> Adapting mature software to new circumstances tends to take more time and effort than writing new software from scratch. Counterpoint: rewriting your code from scratch is the worst mistake you can make. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- knightofmars 8y ago
  It's not that simple, as most things in reality never are. For example, "Spoiler alert: They rewrote Basecamp from scratch and it turned out great. It took around a year, and new signups doubled immediately following the release of Basecamp 2." https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22 https://medium.com/@herbcaudill/lessons-from-6-software-rewr...
  - mark-r 8y ago
    The key to making this work was to keep the old product around, so the rewrite didn't have to duplicate everything the old one did. That both cuts down the amount of effort and insulates you from the undocumented behavior that Joel writes about. If something about the new product doesn't meet your expectations, just keep using the old one.
- jasode 8y ago
  >Counterpoint: rewriting your code from scratch is the worst mistake you can make. Joel Spolsky's essay is more about rewrites of "ugly" code. E.g. Fix the disorganized code by gradually refactoring into cleaner modules over time instead of a total blank slate rewrite. In contrast, this Geoff Greer essay is about paradigm-shifting software architectural changes which by their nature, are very difficult to retrofit into an old existing code base. For these, it's often easier to start coding with a "blank slate" rewrite. As examples Geoff's category of rewrites (new architecture paradigm) vs Joel's category (unhygenic code cleanup), we can look at Joel's ex-employer Microsoft: - SQL Server database diverged from original Sybase code and rewrote the engine. One of the architecture changes was switching from page locks to row-level locks - C# compiler completely rewritten from C++ code base to C# codebase. One architecture change was "compiler exposed as a libary service" instead of being the closed "black box" that was assumed by the C++ code. - operating system: MS Windows NT as a blank slate operating system instead of gradually extending old 16-bit DOS code or 16-bit Windows 1.0 code. One motivating architecture change was the new 32-bit protected mode on the newer Intel 286 & 386 chips. Another factor was the switch from "cooperative multitasking" to "preemptive multitasking".
abainbridge 8y ago
The example of Chrome being written in less time than Firefox took to add multi-process support is interesting. Yes, changing a deeply held assumption in a mature code-base is a nightmare. But, Firefox continued to make releases while they were gradually making multi-proccess support happen. Starting again would have been suicide for them.
- jacobush 8y ago
  And they already did start over once, and it almost was suicide. Instead of gradually fixing Netscape Navigator 4.7, we waited years and years for Firefox 1.0 In the end, it went pretty well and it's impossible to know what would have happened if they would have decided to continue on the Navigator track, but Netscape Navigator reached basically 0% market share until Firefox was released.
  - kalleboo 8y ago
    To be specific, it was 5 years between Netscape Communicator 4.7 (1997) and Mozilla 1.0 (2002)
- agumonkey 8y ago
  I wonder if there are papers on how to restructure large systems. And if modular analysis can reduce the cost of deep+late refactoring.
- bumblebritches5 8y ago
  It's not accurate tho. Chrome is based on WebKit.
bluejekyll 8y ago
"Chrome was written from scratch in far less time than it has taken Firefox to change." This doesn't line up with my understanding of the history of Chrome. I thought Chrome was based on WebKit, therefor definitely not from scratch. Edit: this post references lifting components from WebKit and Firefox in the initial version, https://googleblog.blogspot.com/2008/09/fresh-take-on-browser.html https://googleblog.blogspot.com/2008/09/fresh-take-on-browse...
- FreeFull 8y ago
  And webkit itself was based on khtml, too
- Xophmeister 8y ago
  Sure, but it's not the rendering engine they're talking about, it's just that Chrome was architected from the start to isolate tabs/windows to a process (containing its own renderer) each.
  - bluejekyll 8y ago
    That’s the context in that section, sure, but it’s not what I take away from that statement. Point being, even Chrome would have needed to make WebKit compatible with that model. I don’t know if there was a lot of work to do that or not. But “from scratch” implies that there was no existing code to refactor, which would appear be a false statement.
amelius 8y ago
Imho, terms like "software rot" and "bit rot" are simply disingenuous attempts to blame the software for a malfunction that is caused by changes in the environment of the software.
- ryandrake 8y ago
  Or caused by programmer neglect. If your software compiles today and then fails to compile or run in the future, you could be doing something wrong. Unless your code got hit by cosmic rays and a bunch of bits flipped, nothing rotted. I have code I wrote 20 years ago that still compiles and runs. I could check again but I don’t think any of it rotted.
  - TeMPOraL 8y ago
    The languages and systems change. Some time ago, I had a job freshening up a large, ~30 years old Common Lisp project and it worked mostly fine, with minimum changes attributable partly to evolution of Linux, and partly to some pieces of code being older than the ANSI Common Lisp standard. I don't believe it would be as easy with Python or JS. That said, I don't buy "software rot" as a proper name. Software does not "rot". The concept of rot implies an internal change that makes something fail whether or not the environment around it has changed. This does not happen to digitizes data. Programs only stop keeping up with the Red Queen's race of computing environments.
XerTheSquirrel 8y ago
Software rot definitely hits projects of multiple sizes, you do get better over time programming though so there is always room for improvement.
est31 8y ago
Firefox needed so long for a multi-process architecture because Mozilla focused on other things, like developing mobile operating systems. The main browser was kept in hibernation mode. Also, as the poster said, Firefox had a rich Add-on API that they wanted to keep support for but which they eventually decided to drop. The new API isn't close to the versatility of the old API, sadly some add ons work worse now. A better example would be I think iOS parts of which can't adopt swift and have to stay implemented in ObjectiveC because of binary compatibility concerns.
evrydayhustling 8y ago
I've had my share of frustration with the GIL over the years, but I don't think it fits into the list. Python's rising years have been the same years that we discovered that (a) generalized parallelism is really hard, and (b) many many many applications of muticore are "embarrassingly parallel" and benefit little from shared resources. Stasis around the GIL is a usecase-driven decision to make embarrassing parallelism easy enough (via multiprocessing) and delegate more involved parallelism to linkable libraries or separate services. It helps the language focus on what it's good at.
- war1025 8y ago
  I think for most people, async io / coroutines gets them most of the benefit that they'd ever get out of multi-threading. With async io, you can have a lot going on at once, interleaving nicely while different tasks wait for io responses. Beyond that, normally you're just as well off to kick off a second process. You have to get pretty fancy with algorithms to make multi-threaded computation a net-benefit. Most of the time you don't need that. If you do, you're probably not reaching for python.
- tyingq 8y ago
  I always wondered why there was specifically so much chatter about Python's GIL. If you consider PHP, Perl and Ruby to be Python's main "competitors", they have pretty much the same limitations (not much real world single process concurrency being used) but much less noise around it.
- CJefferson 8y ago
  I agree. Having worked on some long running systems ( > 20 years). Often their success comes from simplicity - - almost any choice different from the GIL, at the time of Python's beginning, would have massively hurt at least one of performance or usability.
notacoward 8y ago
The examples don't seem to illustrate software rot at all. Rather, I'd say they illustrate software ossification. Over time, each example became more rigid and hard to change because things that should have been modularized and isolated in one place instead became idioms pervading the entire codebase. (The "should have" is arguable, I know. There's a broader point about idioms vs. modules that deserves its own blog post.) Rot would be when a program works less and less over time because its external dependencies vanish or change and the program itself stops adapting. Software that is merely rotten can often be saved, with varying levels of effort and skill. Software that is ossified often needs to be replaced.
- meschi 8y ago
  Can you provide an example of rotten software?
  - notacoward 8y ago
    The extreme case is programs for which the entire platform has been abandoned - e.g. DOS (including TSRs), old Windows, old MacOS (including desk accessories). There's a whole "abandonware" community devoted to preserving games that have rotted this way, usually relying on emulation to keep them from being forgotten entirely. There are various file compression/encryption/annotation utilities that have become unusable because they relied on deprecated Windows APIs. Various sound/video hacks on Linux have died as those subsystems remain in constant flux. In my own work as a Gluster maintainer, several pieces such as Java/Python or monitoring APIs have rotted away as those APIs changed. It usually takes a long time for a large program to rot away completely, but individual pieces can become non-functional long before then.
  - Raidion 8y ago
    I think the point OP is making is that there is plenty of bad software out there that (as a result of a combination of incompetence, scope creep, bad decisions, and short timelines) just isn't resilient, testable, and single use anymore. As long as the code is isolated enough, it's fairly easy from a technical standpoint to replace/refactor. Ossified code is code that isn't isolated, but tightly bound to several other components. This means that you can't swap it out without making the exact same architectural mistakes. This means you basically need to start over from scratch, which is a much harder and broader problem.
Cthulhu_ 8y ago
So in all of those examples: Why did the people behind all of those projects opt for a gradual change, instead of a "2.0" from scratch project? Too afraid of losing existing customers or plugin developers? I mean for Firefox they could have replaced the whole base package via the updater. Microsoft ended up doing it with Edge (I believe), doesn't seem to have hurt them much.
- ekianjo 8y ago
  > Microsoft ended up doing it with Edge (I believe), doesn't seem to have hurt them much. Because they had already lost a large chunk of their share.
  - hobs 8y ago
    And further, a lot of microsoft's share of the browser market was defacto share (its the default in the OS) not mindshare - when you choose defacto the enterprises are going to line up behind that, and so edge always has a set of people who follow microsoft's lead regardless of quality.
- GnarfGnarf 8y ago
  Edge has a lot of shortcomings. It fails to correctly render some SVG sites that display properly with Firefox, Chrome and IE.
Scooty 8y ago
> Adapting mature software to new circumstances tends to take more time and effort than writing new software from scratch. Software people don’t like to admit this, but the evidence is clear. Software people love rewriting things. In most cases where I have to maintain an old project I would much rather rewrite it, but it's usually not in the budget.
- badfrog 8y ago
  In my experience the re-write always takes much longer than expected. Sure you might be able to redo the core pieces to handle the new problem in X weeks, but then it's going to take another 4*X weeks to handle all the edge cases and make sure you're not breaking anything your clients/users have grown to depend on. From another HN thread today: https://news.ycombinator.com/item?id=19245485 https://news.ycombinator.com/item?id=19245485 > The first 90% of the code takes the first 90% of the time. The remaining 10% takes the other 90% of the time. And > With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody
  - Scooty 8y ago
    For sure. That's what I meant by "it's not in the budget". I would probably choose to rewrite most projects I work on, but I know it's completely unreasonable for most non-trivial projects. I just meant I naturally gravitate towards wanting to rewrite because clean slates are satisfying.
jancsika 8y ago
> Multi-process Firefox So the claim is that it would have been less expensive for Firefox to start over from scratch and make a new multi-process browser while at the same time maintaining a single-process browser that stayed current with web standards in the interim?
nix0n 8y ago
Full rewrites aren't great either, Netscape[0] is a classic example. [0]https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
bregma 8y ago
It's just software. You can just change it.
niftich 8y ago
I don't agree with that quote being used to define software rot, and I don't think the examples illustrate rot either. I'm just fundamentally opposed to the terminology of the rotting metaphor when it's applied to projects that receive active upkeep, even if the project drifts further from its original scope and vision. For that, we need a name for that that alludes to scope creep and refactoring, but one that isn't suggestive of decomposition at the mercy of the environment of things immobile and abandoned. I've always understood software rot to refer only to cases where the dependencies, including libraries and platform APIs, are changed so that an already-delivered copy of the software can no longer function, and the maintainers have since abandoned it, or can't do a quick fix to get it working again. A recent example is the removal of support for NPAPI plugins in Firefox [1] in 2017. Firefox is in the role of the 'platform API' here, and this change of theirs broke any extension that didn't update. And, the replacement API differs in features, so the effort of updating an extension approaches that of a rewrite. Another example is the game 'Star Wars Episode I: Racer', the podracing game from 1999. Newer versions of Windows and DirectX have changed things so that the game's original executable doesn't run [2]. Even open source isn't a remedy. Random projects one can find on a source repo, last updated x years ago, are code that are susceptible to this. Sometimes they're shipped without dependency management, pinned to old versions that themselves no longer work, or track the latest when they should be pinned instead. If more work is required to get it running than just the instructions provided by the author (assuming those were sufficient at some point), then it has suffered software rot. [1] https://support.mozilla.org/en-US/kb/npapi-plugins https://support.mozilla.org/en-US/kb/npapi-plugins [2] https://www.play-old-pc-games.com/2013/12/02/star-wars-episode-i-racer/ https://www.play-old-pc-games.com/2013/12/02/star-wars-episo...
commandlinefan 8y ago
Joel Spolsky says exactly the opposite: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... FWIW, I think Spolsky is wrong and this Greer fellow is right, but I don't have any particular evidence either way (and definitely not enough to convince the sort of person who rises to a position of authority in a software organization) other than I've seen attempts to incrementally add features to massive software go horribly wrong more often than I've seen throw-it-out-and-start-over go horribly wrong.

Software Rot (2017)

119 points by lelf 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”.
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.

jeletonskelly 8y ago

I thought we called it "bit rot"

overshard 8y ago
"Software rot, also known as code rot, bit rot, software erosion, software decay or software entropy..." https://en.wikipedia.org/wiki/Software_rot https://en.wikipedia.org/wiki/Software_rot
lioeters 8y ago
In my mind, I think of "bit rot" more on the storage level, like hard drives with physically corrupted bits.

jakelazaroff 8y ago

> Adapting mature software to new circumstances tends to take more time and effort than writing new software from scratch. Counterpoint: rewriting your code from scratch is the worst mistake you can make. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

knightofmars 8y ago
It's not that simple, as most things in reality never are. For example, "Spoiler alert: They rewrote Basecamp from scratch and it turned out great. It took around a year, and new signups doubled immediately following the release of Basecamp 2." https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22 https://medium.com/@herbcaudill/lessons-from-6-software-rewr...
- mark-r 8y ago
  The key to making this work was to keep the old product around, so the rewrite didn't have to duplicate everything the old one did. That both cuts down the amount of effort and insulates you from the undocumented behavior that Joel writes about. If something about the new product doesn't meet your expectations, just keep using the old one.
jasode 8y ago
>Counterpoint: rewriting your code from scratch is the worst mistake you can make. Joel Spolsky's essay is more about rewrites of "ugly" code. E.g. Fix the disorganized code by gradually refactoring into cleaner modules over time instead of a total blank slate rewrite. In contrast, this Geoff Greer essay is about paradigm-shifting software architectural changes which by their nature, are very difficult to retrofit into an old existing code base. For these, it's often easier to start coding with a "blank slate" rewrite. As examples Geoff's category of rewrites (new architecture paradigm) vs Joel's category (unhygenic code cleanup), we can look at Joel's ex-employer Microsoft: - SQL Server database diverged from original Sybase code and rewrote the engine. One of the architecture changes was switching from page locks to row-level locks - C# compiler completely rewritten from C++ code base to C# codebase. One architecture change was "compiler exposed as a libary service" instead of being the closed "black box" that was assumed by the C++ code. - operating system: MS Windows NT as a blank slate operating system instead of gradually extending old 16-bit DOS code or 16-bit Windows 1.0 code. One motivating architecture change was the new 32-bit protected mode on the newer Intel 286 & 386 chips. Another factor was the switch from "cooperative multitasking" to "preemptive multitasking".

abainbridge 8y ago

The example of Chrome being written in less time than Firefox took to add multi-process support is interesting. Yes, changing a deeply held assumption in a mature code-base is a nightmare. But, Firefox continued to make releases while they were gradually making multi-proccess support happen. Starting again would have been suicide for them.

jacobush 8y ago
And they already did start over once, and it almost was suicide. Instead of gradually fixing Netscape Navigator 4.7, we waited years and years for Firefox 1.0 In the end, it went pretty well and it's impossible to know what would have happened if they would have decided to continue on the Navigator track, but Netscape Navigator reached basically 0% market share until Firefox was released.
- kalleboo 8y ago
  To be specific, it was 5 years between Netscape Communicator 4.7 (1997) and Mozilla 1.0 (2002)
agumonkey 8y ago
I wonder if there are papers on how to restructure large systems. And if modular analysis can reduce the cost of deep+late refactoring.
bumblebritches5 8y ago
It's not accurate tho. Chrome is based on WebKit.

bluejekyll 8y ago

"Chrome was written from scratch in far less time than it has taken Firefox to change." This doesn't line up with my understanding of the history of Chrome. I thought Chrome was based on WebKit, therefor definitely not from scratch. Edit: this post references lifting components from WebKit and Firefox in the initial version, https://googleblog.blogspot.com/2008/09/fresh-take-on-browser.html https://googleblog.blogspot.com/2008/09/fresh-take-on-browse...

FreeFull 8y ago
And webkit itself was based on khtml, too
Xophmeister 8y ago
Sure, but it's not the rendering engine they're talking about, it's just that Chrome was architected from the start to isolate tabs/windows to a process (containing its own renderer) each.
- bluejekyll 8y ago
  That’s the context in that section, sure, but it’s not what I take away from that statement. Point being, even Chrome would have needed to make WebKit compatible with that model. I don’t know if there was a lot of work to do that or not. But “from scratch” implies that there was no existing code to refactor, which would appear be a false statement.

amelius 8y ago

Imho, terms like "software rot" and "bit rot" are simply disingenuous attempts to blame the software for a malfunction that is caused by changes in the environment of the software.

ryandrake 8y ago
Or caused by programmer neglect. If your software compiles today and then fails to compile or run in the future, you could be doing something wrong. Unless your code got hit by cosmic rays and a bunch of bits flipped, nothing rotted. I have code I wrote 20 years ago that still compiles and runs. I could check again but I don’t think any of it rotted.
- TeMPOraL 8y ago
  The languages and systems change. Some time ago, I had a job freshening up a large, ~30 years old Common Lisp project and it worked mostly fine, with minimum changes attributable partly to evolution of Linux, and partly to some pieces of code being older than the ANSI Common Lisp standard. I don't believe it would be as easy with Python or JS. That said, I don't buy "software rot" as a proper name. Software does not "rot". The concept of rot implies an internal change that makes something fail whether or not the environment around it has changed. This does not happen to digitizes data. Programs only stop keeping up with the Red Queen's race of computing environments.

XerTheSquirrel 8y ago

Software rot definitely hits projects of multiple sizes, you do get better over time programming though so there is always room for improvement.

est31 8y ago

Firefox needed so long for a multi-process architecture because Mozilla focused on other things, like developing mobile operating systems. The main browser was kept in hibernation mode. Also, as the poster said, Firefox had a rich Add-on API that they wanted to keep support for but which they eventually decided to drop. The new API isn't close to the versatility of the old API, sadly some add ons work worse now. A better example would be I think iOS parts of which can't adopt swift and have to stay implemented in ObjectiveC because of binary compatibility concerns.

evrydayhustling 8y ago

I've had my share of frustration with the GIL over the years, but I don't think it fits into the list. Python's rising years have been the same years that we discovered that (a) generalized parallelism is really hard, and (b) many many many applications of muticore are "embarrassingly parallel" and benefit little from shared resources. Stasis around the GIL is a usecase-driven decision to make embarrassing parallelism easy enough (via multiprocessing) and delegate more involved parallelism to linkable libraries or separate services. It helps the language focus on what it's good at.

war1025 8y ago
I think for most people, async io / coroutines gets them most of the benefit that they'd ever get out of multi-threading. With async io, you can have a lot going on at once, interleaving nicely while different tasks wait for io responses. Beyond that, normally you're just as well off to kick off a second process. You have to get pretty fancy with algorithms to make multi-threaded computation a net-benefit. Most of the time you don't need that. If you do, you're probably not reaching for python.
tyingq 8y ago
I always wondered why there was specifically so much chatter about Python's GIL. If you consider PHP, Perl and Ruby to be Python's main "competitors", they have pretty much the same limitations (not much real world single process concurrency being used) but much less noise around it.
CJefferson 8y ago
I agree. Having worked on some long running systems ( > 20 years). Often their success comes from simplicity - - almost any choice different from the GIL, at the time of Python's beginning, would have massively hurt at least one of performance or usability.

notacoward 8y ago

The examples don't seem to illustrate software rot at all. Rather, I'd say they illustrate software ossification. Over time, each example became more rigid and hard to change because things that should have been modularized and isolated in one place instead became idioms pervading the entire codebase. (The "should have" is arguable, I know. There's a broader point about idioms vs. modules that deserves its own blog post.) Rot would be when a program works less and less over time because its external dependencies vanish or change and the program itself stops adapting. Software that is merely rotten can often be saved, with varying levels of effort and skill. Software that is ossified often needs to be replaced.

meschi 8y ago
Can you provide an example of rotten software?
- notacoward 8y ago
  The extreme case is programs for which the entire platform has been abandoned - e.g. DOS (including TSRs), old Windows, old MacOS (including desk accessories). There's a whole "abandonware" community devoted to preserving games that have rotted this way, usually relying on emulation to keep them from being forgotten entirely. There are various file compression/encryption/annotation utilities that have become unusable because they relied on deprecated Windows APIs. Various sound/video hacks on Linux have died as those subsystems remain in constant flux. In my own work as a Gluster maintainer, several pieces such as Java/Python or monitoring APIs have rotted away as those APIs changed. It usually takes a long time for a large program to rot away completely, but individual pieces can become non-functional long before then.
- Raidion 8y ago
  I think the point OP is making is that there is plenty of bad software out there that (as a result of a combination of incompetence, scope creep, bad decisions, and short timelines) just isn't resilient, testable, and single use anymore. As long as the code is isolated enough, it's fairly easy from a technical standpoint to replace/refactor. Ossified code is code that isn't isolated, but tightly bound to several other components. This means that you can't swap it out without making the exact same architectural mistakes. This means you basically need to start over from scratch, which is a much harder and broader problem.

Cthulhu_ 8y ago

So in all of those examples: Why did the people behind all of those projects opt for a gradual change, instead of a "2.0" from scratch project? Too afraid of losing existing customers or plugin developers? I mean for Firefox they could have replaced the whole base package via the updater. Microsoft ended up doing it with Edge (I believe), doesn't seem to have hurt them much.

ekianjo 8y ago
> Microsoft ended up doing it with Edge (I believe), doesn't seem to have hurt them much. Because they had already lost a large chunk of their share.
- hobs 8y ago
  And further, a lot of microsoft's share of the browser market was defacto share (its the default in the OS) not mindshare - when you choose defacto the enterprises are going to line up behind that, and so edge always has a set of people who follow microsoft's lead regardless of quality.
GnarfGnarf 8y ago
Edge has a lot of shortcomings. It fails to correctly render some SVG sites that display properly with Firefox, Chrome and IE.

Scooty 8y ago

> Adapting mature software to new circumstances tends to take more time and effort than writing new software from scratch. Software people don’t like to admit this, but the evidence is clear. Software people love rewriting things. In most cases where I have to maintain an old project I would much rather rewrite it, but it's usually not in the budget.

badfrog 8y ago
In my experience the re-write always takes much longer than expected. Sure you might be able to redo the core pieces to handle the new problem in X weeks, but then it's going to take another 4*X weeks to handle all the edge cases and make sure you're not breaking anything your clients/users have grown to depend on. From another HN thread today: https://news.ycombinator.com/item?id=19245485 https://news.ycombinator.com/item?id=19245485 > The first 90% of the code takes the first 90% of the time. The remaining 10% takes the other 90% of the time. And > With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody
- Scooty 8y ago
  For sure. That's what I meant by "it's not in the budget". I would probably choose to rewrite most projects I work on, but I know it's completely unreasonable for most non-trivial projects. I just meant I naturally gravitate towards wanting to rewrite because clean slates are satisfying.

jancsika 8y ago

> Multi-process Firefox So the claim is that it would have been less expensive for Firefox to start over from scratch and make a new multi-process browser while at the same time maintaining a single-process browser that stayed current with web standards in the interim?

nix0n 8y ago

Full rewrites aren't great either, Netscape[0] is a classic example. [0]https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

bregma 8y ago

It's just software. You can just change it.

niftich 8y ago

I don't agree with that quote being used to define software rot, and I don't think the examples illustrate rot either. I'm just fundamentally opposed to the terminology of the rotting metaphor when it's applied to projects that receive active upkeep, even if the project drifts further from its original scope and vision. For that, we need a name for that that alludes to scope creep and refactoring, but one that isn't suggestive of decomposition at the mercy of the environment of things immobile and abandoned. I've always understood software rot to refer only to cases where the dependencies, including libraries and platform APIs, are changed so that an already-delivered copy of the software can no longer function, and the maintainers have since abandoned it, or can't do a quick fix to get it working again. A recent example is the removal of support for NPAPI plugins in Firefox [1] in 2017. Firefox is in the role of the 'platform API' here, and this change of theirs broke any extension that didn't update. And, the replacement API differs in features, so the effort of updating an extension approaches that of a rewrite. Another example is the game 'Star Wars Episode I: Racer', the podracing game from 1999. Newer versions of Windows and DirectX have changed things so that the game's original executable doesn't run [2]. Even open source isn't a remedy. Random projects one can find on a source repo, last updated x years ago, are code that are susceptible to this. Sometimes they're shipped without dependency management, pinned to old versions that themselves no longer work, or track the latest when they should be pinned instead. If more work is required to get it running than just the instructions provided by the author (assuming those were sufficient at some point), then it has suffered software rot. [1] https://support.mozilla.org/en-US/kb/npapi-plugins https://support.mozilla.org/en-US/kb/npapi-plugins [2] https://www.play-old-pc-games.com/2013/12/02/star-wars-episode-i-racer/ https://www.play-old-pc-games.com/2013/12/02/star-wars-episo...

commandlinefan 8y ago

Joel Spolsky says exactly the opposite: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... FWIW, I think Spolsky is wrong and this Greer fellow is right, but I don't have any particular evidence either way (and definitely not enough to convince the sort of person who rises to a position of authority in a software organization) other than I've seen attempts to incrementally add features to massive software go horribly wrong more often than I've seen throw-it-out-and-start-over go horribly wrong.