Anyone who has seen me harp during a code review knows that I promote and practice defensive programming.  I don’t like to leave anything to chance when I write a public facing piece of code.  It’s my code…I’m advertising how it works (XML comments please and thank-you)…ergo, I’m responsible for how it reacts to various possible inputs.

How did this train of thought start?  Well, at work I’ve been in a series of seemingly endless meetings to discuss the documentation requirements for coded service interfaces provided by one technical team to another.  There are a number of reasons that the meetings seem endless, but one of the biggest is that they always seem to degrade into a discussion about who should be responsible for validating the data being sent to the service interfaces. 

One of the arguments being made in the meetings I’ve been attending is that the consumer of the service interface should be aware of the values that the service considers to be valid.  In my mind this is wrong.  The power and benefit of creating service interfaces is that consumers of these functionalities don’t have to know or care what goes on behind the interface.  To them it is a very, very black box.  To me that’s the argument for programming your service interface as defensively as possible.  Instead the retort that I get is that the service owner doesn’t want to have to manage “…all that validation code when we don’t use it…”  To them I say, provide services at your own risk.