
A Codebase is an Organism - never-the-bride
http://www.meltingasphalt.com/a-codebase-is-an-organism/
======
epalmer
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.

~~~
TrevorJ
>Its like razing a child

Spelling may be unintentional, but it's still accurate: sometimes you gotta
tear down your code to build it up again stronger and more elegantly.

------
mcdonji
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...](https://edge.org/conversation/richard_dawkins-this-is-my-vision-of-
life) 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.

Crazy thoughts for today.

------
RyanMcGreal
Some contradiction here:

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

~~~
mmwako
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 :)

~~~
andrewflnr
"Changes" are like simple heat. "Interventions" are changes calculated to
reduce entropy.

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

------
booleanbetrayal
This really encapsulates a lot of lessons learned over the years. Great read!

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

[0] [http://250bpm.com/blog:51](http://250bpm.com/blog:51)

