Do you identify errors when designing your application? When developing a technical specification, every analyst should know, and account for, the possible errors that can occur in an application. It’s commonly known that no application should cause an ABAP dump but, unfortunately, I still see this happen. I also believe that every analyst and developer should be able to tell you what happened within their application when an error occurs. When performing a detailed technical design, the possible error should be trapped and, I would argue, the error message should be identified by an analyst and not the developer. Why?

Let’s consider this example. I design an application, send it to development and then test it. One of the unfortunate tasks is that a majority of applications are tested for positive results and not for negative results. To keep the cost of an application down, most companies perform what I would call adequate testing to ensure they get the results they are expecting, but pay little attention to the results when something goes wrong. I was reading an article in SD Time today about software development failures. What struck me about some of the major failures mentioned is that they were about what the application does when something is wrong. The best example was a Philadelphia man who could not get a drivers license because he was marked as deceased. The application had no way to resurrect him so this was a failure in the design not in the application. I’ll write a more detailed blog about that later, but one thing I can encourage you to do right now is to identify the errors that are possible in the application and identify what you want the application to say in the error message. Identify these either in your design, such as below, or at least document an error table the identifies the error and the associated error message.

How will this help? There are two main benefits:

  1. The user has a better idea of what to do. Have you encountered the famous “Memory low. Leave the transaction before taking a break.” within SAP? How completely unhelpful to the user. The developer should not decide what the error message should say, unless the developer is also the analyst and he understood the process and could determine what to tell the user.
  2. The future. You need to think beyond the initial roll out of the application. Why? The majority of problems happen months after an application is deployed. Things change even if the application does not. To support an application, an analyst needs to think about how they will determine what went wrong six months from now. When an error occurs, a lot of time is spent trying to understand what caused the error (debugging, testing etc.). The real impact is the lost productivity by end users who are affected by the error. What if the error is causing a customer order to not be processed? We had a recent example where a complex ABAP application was giving a useless “Cannot determine” error. This error was the generic error message kicked up in many of the areas within the code. After spending hours debugging the application, the error was determined to have been caused by a user time zone that was set incorrectly. It would have been helpful to know where in the application this error was occurring along with a more meaningful message.

In summary, do yourself a favor and understand possible errors ahead of time and document and provide your developer with the error message that should be displayed. Your applications will be easier to support and you might just have end users solving their own problems.


Pin It on Pinterest

Share This