Developing for After - October 2014
During the application development process, we strive to meet the requirements of the customer. What often falls out of sight is the time after the application is deployed by the customer. Thinking past development is a key factor to success.
Along with my years doing application development, I spent a fair amount of time in application support and operations, both as a support engineer and a support manager. There have been many a time where the application being supported had issues that had to be tracked down. Some applications made it easy to diagnose, while others caused no small share of headaches in this process. When developing applications, you should plan ahead on how someone would be able to identify problems in your application, especially if they do not have immediate access to the source code at the time. There are two concepts that should be considered to help with this situation: logging and debug mode.
What should be considered for any application is logging of information. This could be logging of each operation that the application is doing or logging the details of an error. This could be writing to a text file in the application directory, storing the data in a database record, or even the operating system event log. At the very least, each error should be logged with enough details to know where the error was and what the application was doing at the time of the error. Logging is very important to applications that are process based and do not have a user interface. This helps find problems to processes where there is not an error message popping up on a user’s screen.
Another concept of logging is logging detailed information about the application processes. This is known as verbose logging. Verbose logging is capturing as much information about the process that you can to help describe what is going on in the application. This is not logging each line of code, but rather logging each step of a process. Normally, verbose logging is not turned on by default due to the amount of information that is outputted. This is normally set in a configuration file or via some command in the application.
Debug mode? I am not talking about running the code in Visual Studio, I am talking about running the application in a controlled debug mode. Debug mode is normally set in a configuration file or via some command in the application. There are different scenarios for using debug mode. One possible scenario is having the application run using a specific set of parameters. An application might do different actions based on the user logging in. A debug option would be to allow the application to run as a different user to see what the output would be like. Another scenario would be a data processing application that manipulates data and saves it. The debug mode for this might process the data, but not save it. You might not always output the results of debug mode to the client. Here is where logging comes into play. Often, in debug processing the information is logged, very often in a verbose manner, providing a detailed view for analysis.
When you are developing your next application, in addition to who will be using it, think about who will be supporting it.
- Andy Macourek, Principal Technologist
Blueprint Consulting Services