Preventing Broken Windows
Ryan Foster, Former Developer
When you see poorly written or poorly executing code in a project you've inherited, what's your first reaction? It probably depends a lot on context. Is it cruft? Meh, its not hurting anyone (yet). Is it failing on edge cases? I'll fix it when someone complains. Is it one of several sore spots immediately visible? This whole thing is junk and it's too painful to fix.
The last phenomenon is a regrettable reaction to software entropy, but I bet you've felt it more than a few times.
The approach to tackle these Broken Windows is direct. As the theory goes, one broken window will quickly lead to more so fix them immediately. Programmers are police on the beat keeping the code base clean.
Cool story bro. But don't end the conversation there.
In most cases, broken windows aren't the problem. They're a symptom. It's not enough to just fix a broken window. It's worth the time to ask why it broke. What's the real problem here? If you have an honest assessment of that, then you can design to prevent broken windows. I think that's where this conversation needs to and as far as I've seen it, fails to go.
You can't avoid the pain of windows that are already broken. You can use it as a guide to prevent your own software's entropy.
- Don't design elaborate windows when one or many simple windows will do. Whether you call it KISS, the Unix philosophy, Occam's Razor, etc.; you ought to believe in it. Minimal designs are less prone to breaking or becoming obsolete. And when they do break, your fellow developers won't feel the pain. The problem and solution will be much clearer.
- Put the duct tape away when you're pressed for resources. Especially in pre-launch quality assurance development. It's tempting to hack some code to solve the problem fast. You even convince yourself that you'll fix it properly when you have more time. You may not always have a choice, but resist if possible. Even a few hacks have an amplifying effect just like a broken window.
- Vet your design and be prepared to explain. Can you logically defend your decisions or does it just work? Do the reviewers believe your tests? The process goes a long way to mitigate 1 and 2. Pooling experience will make your code more robust. You'll avoid pitfalls already seen by your fellow developers now and in the future.
The flip side of each of these points is alluring: trying exotic new technologies, whipping up code quickly, and going solo for days or weeks. While appropriate for spiking, it will cause real pains in production code. It's tempting for the immediate gains but will lead to a lot of broken windows.