This article resonated with me. Note that currently I don't work in a team development environment. There are 3 of us and we each have our own respective technologies we develop for or with. One of my responsibilities is some Java backend code. I'm 80% of the way done developing a complex routing system that runs under apache camel. I'm maybe 150 hours into the development.
As it relates to this article, even when developing a new system I find I have to keep challenging my original assumptions and refactor out the complexity where I can as I go. Its like razing a child and impacting new life rules each few months.
Yesterday I realized the customer had provided some requirements that we wrong and now I have to go factor that into the code in the next couple of days. I am so glad that I have unit tests. I will be rewriting several unit tests today and adding more and then write the new requirements into the code base. It feels like when you have a child and wake up in the morning ready to go to work and your child says, Dad take me to the doctor I don't feel so good. All of a sudden your day or next several days are not what you had planned for but still you have to proceed with the new path.
I'm surprised this isn't getting more attention. I have used this metaphor of code as a living entity before and it resonates with those that have lived through such growth. The article beautifully articulates this idea. I think this idea extends to ideas or memes in the
https://edge.org/conversation/richard_dawkins-this-is-my-vis...
dawkins view of battling evolving concepts. The code swarm is a visualization of a one such concept. I think in the enterprise world I see this lots with business process but there is no concept of even writing the business process down let alone visualizing the process over time and the idea of culturing a business process is not even on the radar.
Code doesn't decay on its own, of course. Left completely untouched, it will survive as long as you care to archive it. Decay — often called code rot or software rot — only sets in when changes are made, either to the code itself or to any of its dependencies. So as a rule of thumb, we can say that most code is decaying during most of its existence. It's like entropy. You never 'win' against entropy; you just try to last as long as you can.
In a healthy piece of code, entropic decay is typically staved off by dozens of tiny interventions — bug fixes, test fixes, small refactors, migrating off a deprecated API, that sort of thing. These are the standard maintenance operations that all developers undertake on behalf of code that they care about. It's when the interventions stop happening, or don't happen often enough, that code rot sets in.
In the first paragraph, the author says that code doesn't decay if it's left alone but does decay when it is changed. In the second paragraph, the author says the exact opposite.
A warning about the hazards of reasoning-by-analogy: you've got to be really clear in your head about how the analogy maps to the subject.
I think you misunderstood what he is saying (or maybe he wasn't clear enough): in the first paragraph he says that code decays when it is "changed", meaning when the codebase is enlarged, grown, more functionality added. On the second, when he talks about interventions, he's not refering to the same kind of changes, but to "code maintainence", which is a distinct and different kind of effort, the one that prevents the decay. For instance, from his point of view, a unit test is not a change to the codebase, but an intervention. Therefore, the codebase organism enlarges and rots with more code added, and bug fixing, test, refactors, etc, are the efforts needed not to rot. (Conclusion: the analogy is not the culprit :)
I found it dismaying to know programmers who believed in creationism because they work with stuff that is so evolutionary.
Now I kind of get that you have to come to something with the right perspective to see 'properly', but... so dismaying initially. I felt a desire/need to be among some people who were similar to me -- had a lifetime worth of being different already -- and it wasn't happening.
> code rot or software rot — only sets in when changes are made, either to the code itself or to any of its dependencies.
"dependencies" is so vast here, that this definition (and following discussion) is completely useless.
A web browser "depends" on web standards - Netscape 3 rotted not because of changes, but because it didn't even support HTML4 and the web moved on.
Older games "depended" on hardware CGA/EGA/VGA quirks, or CPU timings, that were not replicated in later models.
Year2K bug is "rotten" because 30 years have passed. The dependency is on the calendar year needed to operate in.
And while we're talking about software as an organism, I believe Martin Sústrik's "Software Component's Reproductive System" essay[0] deserves more attention.
As it relates to this article, even when developing a new system I find I have to keep challenging my original assumptions and refactor out the complexity where I can as I go. Its like razing a child and impacting new life rules each few months.
Yesterday I realized the customer had provided some requirements that we wrong and now I have to go factor that into the code in the next couple of days. I am so glad that I have unit tests. I will be rewriting several unit tests today and adding more and then write the new requirements into the code base. It feels like when you have a child and wake up in the morning ready to go to work and your child says, Dad take me to the doctor I don't feel so good. All of a sudden your day or next several days are not what you had planned for but still you have to proceed with the new path.