The Two Kinds of Defensive Programming
May 14, 2009 10:21

I made a few points in last week's presentation on which I want to expand a bit. One of them is about "Defensive Programming"

There are two kinds of defensive programming - the good kind and the common 'flinchy' kind.

I learned about the Good kind of defensive programming in the changed-my-life book The Pragmatic Programmer. The key concept in defensive programming is to assume Murphy's Law is going to happen to your application, and write your code to be able to handle it. A few techniques I often practice are:

• Asserting that proper values have been passed to any important or complex methods
• Double-checking that the current user has proper access to the objects and elements being worked with
• Being smart about when to break out repeated code into functions, objects, and methods (which sometimes means I don't)
• Using delegates and the Law of Demeter to hide composition and implementation details
• Having sensible defaults to 0 or '' for missing data, unless there's a good reason otherwise

There are many other aspects to defensive programming that can be found in The Wikipedia Article.

But there's a much more common kind of defensive programming: the kind done by scared programmers. I sometimes call it 'flinchy programming'. They're inexperienced, they don't know the language or the framework very well, the application they've been assigned to work on is messy and complex, and they're likely to be in an unhealthy authoritarian work environment with an overbearing boss.

It's fairly common that when a project starts to collapse, the good programmers shy away from it, or management decides that it's not worth wasting good resources on it anymore - so more junior staff get assigned to it, who are out of their depth and on bad project schedules.

Usually, 'flinchy' defensive code is written very quickly, with no regard for reliability, maintainability, or legibility. The only thing on a defensive programmer's mind is to get it working 'well enough to not get fired'.

Common techniques in the bad kind of defensive programming include

• copying-and-pasting rather than building a function or a method, since "there's no time for thinking about it!"
• writing their own custom string or array management methods instead of using existing ones already in the language, framework, or application, since "I can't go through all of that documentation!"
• if existing functionality isn't working properly, working around it instead of fixing it
• blindly using code generators or wizards to build functionality that they don't understand

We've all written our share of 'flinchy' code - I certainly have - and usually it has been written at 3 in the morning right before some arbitrary deadline. Some people, however, only write this way.

'Flinchy' defensive code is often easy to fix - the difficulty is in figuring out what they were trying to do in the first place. On the Careerious rewrite, a junior C# programmer had to implement a piece of PDF report code that displayed three paragraphs based on 9 criteria, so he copied-and-pasted the same 15 lines of code 27 times and changed the number reference in each case. I simply wrote a separate method, which took the passed number reference, and I called it from a loop that went through an array of the appropriate values.

'Flinchy' defensive programmers are often harder to fix. The key - especially if you find yourself doing it - is to slow down and relax. Athletes and writers and martial artists and musicians have all learned that you can't perform at your best if you're jumpy and nervous: there's power and strength in relaxation. Take ten deep slow breaths, go for a walk, or have a glass of water. Then look at your code again and see if you can work smarter instead of harder.