The second law of software thermodynamics:
Your code tends toward higher entropy. — Brandan Lennox, 2012
The more code we write, the harder it is to tell useful code from useless code, and the longer it takes to turn the latter into the former.
These examples all come from our Rails project at work.
- For three and a half years, the code, which isn’t public or user-accessible, still contained the default README and an empty doc subdirectory.
- We use Workling for background jobs. Mainline development on Workling stopped in 2009, and it’s no longer compatible with Rails 3.1. Same with Machinist.1 Same with Spork.2 Our adoption of a project is a death sentence.
- Until recently, we had four separate subdirectories housing executable scripts:
scriptis Rails-sanctioned (and necessary).
- We have to execute asset precompilation in a custom Rails environment — i.e., we can’t use the
productionenvironment like you would expect. I don’t know why. In addition to that, one co-worker recently created his own environment for development. I guess he wasn’t happy with
production, so he combined the two. So now we have 66% more execution environments than a normal Rails project.3
- Speaking of environments, we have a custom initializer for our test environment that adds 10,000 to the current autoincrement value for the
idcolumn of certain tables. That’s how we fixed a conflict between Postgres, fixtures, and Machinist. We’ve switched from Machinist to FactoryGirl, but we left that initializer in place because insert reason here.
It’s not just a matter of refactoring. I find a lot of code that isn’t even executed anymore. It’s just taking up disk space and attention, but you can’t know that until you spend the time to figure out what it does.
And it’s not just a matter of compulsion. The problems I listed above really do hurt us:
- Okay, maybe not this first one, but…
- We missed a release date because of a bug in Workling that we didn’t find until the very end of the test cycle. By then, we didn’t have time to replace Workling with a current tool, so we hacked around the bug and released. Is that going to bite us once it’s out in the field?
- If I want to create a new executable script, which directory am I supposed to put it in? What’s the difference between a runner, a script, and a util? Who’s executing these scripts, and do they have a good reason for this arbitrary directory layout? Why am I having to make this decision?
- Why did someone have to create a
precompileenvironment? How is it different from
production? How do we know if a future version of Rails fixes whatever problem we had with asset precompilation?
- We spent so many hours fixing problems with Machinist that were never going to be fixed by its developer. But FactoryGirl seems to work fine. Do we still need to futz with these autoincrement values? It slows down our tests and represents a significant break from normal development. Is something else depending on that behavior, or can we get rid of it?
I need to learn to balance my compulsion for pristine code with my requirement to produce. It wasn’t a big deal when I worked by myself because the projects were small, short-lived, and completely owned by me. Now, it’s not just a poor use of time, but it creates tension between you and me if I’m always rewriting your code without good reason.
In related news, I’m going to start writing a lot more code for myself :-)