Too many times I’ve seen developers spend a ton of effort building an application, getting the feature set just right, adding additional features (see previous post on keeping it simple), etc.. then launch the application and assume all is well. These are important parts of application development indeed but building the application is only the first step. Launching and support of the application are the most visible tasks in the process and also can be the most difficult. Building software is easy, building good software that is supportable and maintainable is hard.

The good news is there are several ways to make the lives of your users, your clients, your support staff and any other individuals who may have to support your applications easier.

• When your application breaks it should break loudly! No this does not mean you should just dump a ton of error information to the screen for your users to read. No one wants to see that. What it means is you should put together a nicely formatted error page, clean up the error if you can or show a generic error to your user. Make it perfectly clear that something went wrong with your application but present it in a way that the average user can understand and won’t think the world is coming to an end when they see the error page. You should not try to “gracefully” recover from most errors, especially those where there is no real recovery path only attempting the same action again.
• When your application breaks tell someone who can fix it! You’ve notified your user that something went wrong. That’s a good start. Now you need to tell someone else who can fix the problem. At a bare minimum an attempt should be made to email support staff. In several of the applications SDP has developed we’ve also built an administration console that displays in real-time any application errors that have occurred. Support personnel generally spend the day with this console open so they become aware of any errors within minutes.
• Logging, Logging, Logging! When something breaks you have to be able to determine what exactly caused the problem. In a production application you can send a message to the end user “Here is the problem please contact support and give them error code blah blah blah…”, try to include that information in an email to support or utilize the tried and true practice of logging. Of the 3 I believe the best option is to enable logging whenever an error occurs and be very very verbose in your logging. If you’re logging error information correctly you should be able to determine a) where in your application the error occurred and b) exactly what state the application was in at the time. That said don’t start recording additional data just because it may be needed at some unforeseen point in the future. There are some nasty side effects that come with recording too much information, most notably it is very easy to make your application drag like molasses. So when logging capture lots of information about the error and ignore logging when the application is running along just fine.

It’s important to know what will become of your application after you’ve developed it. Just keep in mind that building an application is just the first step in the process and you’ll need to plan for those individuals who will be taking on steps 2, 3, 4, etc…