People come and people go. But the code base stays there. It evolves over time, like an amorphous organism. It mutates (or is, rather, being mutated) to meet the changes in its environment. Some of its parts don’t always function as expected, requiring a surgical procedure to try and set those parts on the right path. And if you’re not careful, it can swallow you whole and nobody will hear from you ever again. Analogies. They always break apart at some point.

Last December marked my fifth anniversary on my current project. The codebase has been there before me (perhaps a year or a bit longer), and since then it has seen significant changes. I doubt that there’s any single line of code that has survived untouched in all that time. Some modules have been rewritten completely. Some have been rewritten completely more than once (hello local app history management). Certainly none have remained in their original form or function as we’ve moved through multiple rounds of redesigns that were (almost always, hello all things Material) driven by evolving business requirements.

And beyond all the feature changes, there are always bugs. Sometimes they are in my code. Sometimes they are in this code that this other person wrote, and it just so happens that they are half way across the globe enjoying their vacation just as we’re closing down on this year’s I/O and seriously who does that. OK, that was too specific. And sometimes bugs happen to be in the module that was last touched by this guy who’s no longer on the team and not even any longer at the company.

Clarity and brevity are your only [citation needed] two weapons to help you wade the murky waters of code that is not old enough to be completely replaces but not young enough that you can actually remember either writing or reviewing it. Complexity, on the other hand, is your worst enemy. Back to analogies!

Complexity is an affliction that attaches itself to this one part of your organism. And it’s not going away on its own. Next time you’re in that module, fixing a bug or extending the functionality, that complexity winds itself into the new code, spreading just a little bit farther in. And then it intersects with another affliction that originated in another part of your organism. At the time, both afflictions were pretty local and pretty small. But they were left unchecked, growing just that much bigger every single time somebody touched things around them. And now they are intertwined.

And at some point you have that thing in your organism that everybody’s afraid to touch. Nobody has any idea how to make it better. Nobody has any idea what side effects a specific surgery (aka bug fixing) will have. It might have taken you a couple of hours at the beginning of the next release cycle to go back and treat that original affliction because you just didn’t have enough time to be clear and brief. But ain’t nobody got time for that. That’s not glamorous work. That’s not work that you put up in your promo packet. That is work that can only be appreciated by people who have spent at least a few years on the same code base.

Complexity is by far our worst enemy. Well, that and software patents. But that’s a whole another subject.