Coding principles: The difference between defensive and offensive programming

I put together a list of strategies, rules and best practices for our team. This is not any unusual stuff, but (IMHO) a sensible and smart set of rules to follow to be able to write extensible, maintainable, understandable, testable, robust,… *TooManyAdjectivesException* …code. To follow the evolution of methodic and what are the coding principles we do follow have a look at Evolution of methodic.

Have a look onto that part of the rules. I did put it together in a powerpoint – yes, the most beloved tool of every developer. 😉

So how can we be defensive while being offensive? Isn’t that paradox?

No, it isn’t. Let me tell you my understanding of both principles. You may want to add your 5 cent when you disagree.

Defensive programming:

What does make the developer being defensive? Hold back anything? Don’t do the full story? Try to get rid of the feature when the product owner talks about it? There is a wiki entry about defensive programming. This definition doesn’t go far enough and partly goes into a wrong direction from my point of view:

Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances. Defensive programming techniques are used especially when a piece of software could be misused.

Let me put my set of rules of being defensive. Let’s say the developer has to implement a certain feature:

• The developer writes the code that is necessary to implement the functionality that is neccesary for providing the feature to the user. This is the “short programme” in terms of ice skating. You won’t win the gold medal with that.
• The developer defined an architecture that is sustainable. He did this before he wrote that feature. He just laid back and thought. Maybe for some minutes. Maybe for some hours, depends on the size and complexity of the feature. This is maybe the time, when people passing by thinking “what is he doing? I would love to be a developer, because they can sit around doing nothing.” These guys are pretty wrong. This is the bad ass part.
• For that part, the developer needs to ask the right questions, usually the part of the expert. Have a very impressive read about that on one of my favorite blogs from Jeff Atwood in Are you an Expert?
• The developer gets the big picture.
  • He knows all the constraints
  • He knows what can go wrong
  • He knows what needs to be accomplished
  • He knows the details. Let me put an brief example: Do you need WCF communication? What do you do when you get a timeout? Do you repeat the call? What happens when repetition fail? 
• The developer writes code being aware of all these circumstances and conditions.
• He knows exactly how to do proper exception handling. He will never swallow an exception unless he has a very good reason to do so. The latter would be documented. He knows exactly how to bring descriptive exceptions up to the user that the user is able to act on misbehavior.

Offensive programming/ Fail fast:

The offensive programming is more easy to describe due to it is a way shorter story.

Being offensive/ fail fast means:

• When your code cannot handle an exception, it shouldn’t.
• When your code cannot add any information beside the stack trace (which is already available), you don’t throw your own exceptions – and you don’t re-throw anyway
• You code doesn’t swallow exceptions because “you just don’t know at this time how to handle this”
• Another well known one that you would never do is: “I will care about that later, like with the logging. Just have no time at this moment, need to finish that feature.”
• You want to make sure in every single line of code that you’re doing the right thing.
• You want to keep your code simple, thus you only care about things in your code that the code is responsible for. Don’t mix it up.

From my point of view, offensive coding/ fail fast is part of defensive coding. Nevertheless, both needs to be mentioned.

You can consider the defensive developer

• to be the humble guy that asks the right questions
• puts out the absolute necessary code and not more
• has the big picture thus created a sensible architecture
• created maintainable, understandable and extensible code

This is exactly the type of developers we need.

Are you one of them?