How best to avoid a code collapse catastrophe

18 Sep 2013

I’ve been developing on a myriad of platforms for a few years now, and somewhere along the line I decided that gave me the right to tell others what was good and bad about their code. Before you dismiss me as arrogant, let me espouse for a moment on the value of peer review in code.

There are few fields so complex or nondeterministic as programming computers. Even quantum physics has the benefit of consistency within its own framework, but programming is a human metaphor built atop a human metaphor built atop our imperfect understanding of the flow of those selfsame quantum thingies. It’s what theorists call a chaotic system – a closed (self-contained) system where all of the outputs can be controlled by any one of the inputs due to internal feedback loops. Really, what this means is that you have no idea what went on between typing “doThis();” on your keyboard and the computer doing the particular “this” you intended.

So when I say that even as one of the more self-important and egotistical programmers I know, I still accept the necessity of letting others critique my work. No one’s perfect, and no one can catch everything. I’ve screwed up everything from system firmware all the way down to a plain old “Hello, world!” with single-character typos I never saw! And most mistakes in programming are a lot more subtle.

Peer review is a concept well understood by even the most disconnected managers. What I really want to rant about here is a somewhat less known idea: technical debt. If you’re a programmer who’s worked on any type of project and have a project manager who doesn’t code themselves, you’ve almost certainly had this conversation:

Developer: “We need to set aside time to update the frobulator to the latest version.”
Manager: “What’s the benefit to doing that?”
Developer: “We’ll be up to date, get the latest fixes and have an easier time moving forward.”
Manager: “Hmmm. I don’t understand how that helps us meet our schedule right now. What does it change about how the project works right now?”
Developer: “Well, nothing right now. It’s just important for the future.”
Manager: “Then worry about it in the future. Right now, just worry about getting things done before the deadline.”

It’s true, the changes that developer wanted to make would have had no effect on how things were working right then. Deprecated APIs (features in the underlying OS that are going to be removed) continue to do what they’ve always done, less modern code still functions, and that module written by that guy who left the project and the company six months ago still works, even though no one understands why.

Here’s the problem: Deprecated APIs are eventually removed. Legacy code eventually becomes unreadable. That former developer’s module eventually breaks on a new OS version. Now, what was preventative maintenance has become a critical problem that can’t be put off. If it hasn’t been put off too long already, then you’re probably okay. If you’ve been pushing back and pushing back and pushing back the refactoring and updating and rewriting, you’ve got a project that suddenly needs to be practically rebuilt from scratch just to keep doing what it always did. Some project managers have enough experience to understand this problem. Maybe they’re coders themselves, or maybe they’ve encountered it before. Maybe they’re incredibly lucky and have developers working on their projects who know exactly how to put it in terms a non-coder will understand.

That latter is surprisingly rare; by and large, us coders are not the best at rephrasing things in normal-person talk. Faced with deadlines of our own, and sharp questions from managers legitimately concerned with meeting their deadlines and not overrunning budgets, many of us will simply retreat to our monitors and swear up and down to fix the problem in our spare time. But on a big project with multiple people working in concert, you really have to coordinate this kind of upkeep, and not everyone is going to be as devoted as you to maintaining what’s effectively two versions of the code during the time they set aside to focus on hang gliding or kayaking or being with their families. The “spare time” solution inevitably falls so far behind it’s not even worth the effort.

Of course, even the managers who do understand the problem have to put up with overzealous neat freaks like myself — developers who have a tendency to confuse technical correctness with incorrect code. As a result, project managers have to constantly balance the difference between real technical debt — changes that do nothing now but have a significant impact on the future of a project — and fake debt — changes that don’t mean anything to anyone except the person making them. It’s no wonder they often say “no” to everything and focus their limited time on more important matters.

The point is, if you’re a coder, take a moment to appreciate the effort your project manager puts in to keep things on an even keel, like I do at Chaotic Moon. If you’re a PM yourself, take a moment to pat yourself on the back for doing a good job (assuming you have, of course). And if you’re upper-level management, take a moment to consider how much work you’re not doing because of your underlings, and consider that when you’re calculating how much of the budget to put into end-of-year salary adjustments! A girl can dream.