Can Your Code Survive in the Wild?

Software projects are much like animals in a zoo, which often thrive in the confines of their cage but cannot survive if released to the wild. Perhaps they don't know how to forage for food, kill their prey, or evade predators. Regardless of the reason, the point is this: not all animals can survive in the wild. The same is true for software.

In the case of software, "the wild" is the Enterprise Environment. It is the most hostile, unforgiving habitat for code.  In fact, the vast majority of code written is unfit for the Enterprise Environment.  Too often, developers raise their software in the confines of their local development environment - it looks good, it works, it passes all the unit tests - but it isn't ready to be released to the wild.

Only the most fit, most evolved software can survive this hostile environment. As software developers gain experience, the software they produce evolves as well. In broad strokes, the stages of evolution look something like this:

1. Software that works. The first thing developers learn is how to write software that satisfies the functional requirements of the client. They know they have succeeded when their software passes functional testing. Good developers will even create unit tests to validate their success.
2. Software that is elegant. Satisfying immediate requires is good, but an elegant solution is better. As developers mature, they learn good Object Oriented development strategies. They learn how to apply Design Patterns. They learn how to write sofware that is modular, reusable, and maintainable.
3. Software that breaks.  Huh?  Let me explain...

Developers that have worked in the Enterprise Environment long enough understand that "stuff" happens.  Murphy's Law is alive and well.  Servers go down, connections get dropped, credentials change, permissions altered, disk space fills up, and the list goes on... 

Before software is ready to "survive" in the Enterprise Environment, it must be able to respond appropriately when things go sideways.  It's not enough to simply write a generic error message to System.out.  Our Enterprise clients expect more; they deserve better.  As developers of Enterprise software, it is our job to figure out how deliver a robust, intelligent system that is ready for anything. 

We need to think a few steps ahead and answer a few very important questions:

1. What are the failure modes of the system (what are the different ways the system can break)?
2. In each failure mode, how will the system know if something breaks?
3. Can the system automate, or otherwise facilitate recovery from these failure conditions?
4. When and how will someone be notified about the error?    
5. Who should receive the notification? 
6. How will they be notified?
7. How will we know where the error occured and what the conditions were that caused to the error?  

Answering these questions will help us develop robust software that is equipped with some essential survival skills:  error detection, reporting, troubleshooting, and recovery.  With these characteristics, our software will be ready to thrive in the Enterprise Environment.