introduction of defensive techniques. As customs agents, we seem more and more willing to "profile" our clients and immediately determine that they meet our "trusted" client criteria. It's as if almost everyone gets the benefit of the doubt.
At times, we behave as if we've all been given crystal balls. We now have the ability to look into the future of all the code we write and know how it will and will not be used. Given this foreknowledge, we have the ability to decide if our code really warrants the investment in creating all this extra defensive code. This phenomenon is often referred to as "happy path" programming.
Happy path programmers take a very optimistic view of their clients' behavior, treating defensive programming with the caveat that it's exclusively reserved for coders who might be working on the space shuttle. My biggest problem with happy path programming is that it seems to suggest that we only need to worry about the here and now and that any future variation that could break our code isn't worth considering. Perhaps that's the real issue here. Do we need to consider the future of our code now? Do we value its ability to gracefully detect and report errors that may not be produced today?
Of course, the underlying reality is that being a customs agent isn't exactly a fun job. After you've looked at a few hundred passports, the job can start to feel a bit repetitive and even mundane. We'd all much rather be writing the latest image recognition code that will automatically identify every face that tries to cross the border. That's much more intriguing than protecting that code against the occasional invalid request.
So, does this mean that all of your code should be written defensively and that we should all be the most paranoid, anal-retentive programmers we can be? Definitely not. Certainly, in some environments, there will be times when this level of robustness will be critical, and there will be some environments in which it will be excessive. The key, from my perspective, is to be less willing to assume that the code you write today will always have trustworthy clients. I'd rather be protected against a potential error than assume it will never occur.
The reality is that software has a natural tendency to evolve in ways we may not expect. If you're going to be a defensive programmer, you're going to have to be willing to defend against the behavior of clients today and tomorrow.