Fear is dangerous, as it feeds off itself, growing and multiplying, taking your development workflow into a downwards spiral. Somebody was in a rush and left a hard to understand chunk of code around — poor naming, incidental complexity, wrong level of abstraction, lots of possibilities here. Next time around, somebody is touching nearby code, and they are also in a bit of a rush. The questionable code looks daunting, so instead of understand it and cleaning up, the thinking goes “oh man, this is a pain to deal with, let me just code around it”. That’s fear, stage one. Branching is added, dealing with the mess is avoided, and the developer moves on. Some time passes, and the next visit to the code is required. Now things are much uglier, and the thinking goes “oh man, this is a pain to deal with, I don’t even understand it, and there’s a bunch of branching, so multiple cases to consider, I’m sure even if I fix whatever I’m here to fix, I’ll break something else and not know how to test for it”. Guess what happens then. New hacks and branching to facilitate the fixing of the bug with minimal exposure to the offensive code. The result — we’ve just further expanded the amount of offensive code.
The results of this kind of approach can be frightening. Cruft is exponential, and so is fear. Adding a simple level of branching to crappy code doesn’t double the complexity and unapproachability of the code, it squares it. And the messier code becomes, the less likely someone is to dive in and understand all the use cases (which are guaranteed to be simpler than the organically involved code accomplishing them, so simplify complexity and notice abstractions early). Fear will spread to adjacent code, and if left unchecked, will infect the entire code base. Developers lose the sense of control, get defensive, and then all hope is lost, the code is a mess of spaghetti, and feature building progress grinds to a near halt, more time wasted on fixing regressions than on moving forward.
Understand reasons for fear, and proactively keep your code base fear-free.
As far as tools for fear-fighting, a special mention goes to type safety. Knowing that the complier has your back for a number of classes of bugs allows you to be brave about proactive refactoring, and refactoring is a key cleanup tool. If you’re empowered to clean up proactively, fear has little chance.
Comments
Post a Comment