Who Do You Trust?

[article]

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.

About the author

Tod Golding's picture Tod Golding

Tod Golding is the founder of Blue Puma Software, a technical consulting company that provides software training, mentoring, and development services. He has twenty years of experience as a software developer, lead architect, and development manager for organizations engaged in the delivery of large-scale commercial and internal solutions. Tod has an extensive background leveraging .NET, J2EE, and Windows DNA technologies, which has allowed him to become equally skilled with C#, Java, and C++. He has worked and consulted at a variety of companies, including stints with Microsoft and Borland. Tod is the author of Professional .NET 2.0 Generics and a contributing author for the XML Programming Bible. Tod can be contacted at tod@bluepumasoftware.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 24
Oct 12
Nov 09
Nov 09