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. I think it’s pretty commonly known that no application should cause an ABAP dump, unfortunately I still see these happen but I believe also that every analysts 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 that even the error message should be identified by an analyst and not the developer. You ask why?
Well 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. I can go on about this but the realities are that to keep the cost of 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 and what struck me about some of the major failures they mentioned is that they were all about what the application does when something is wrong, the best example was the Philadelphia man who could not get a driver’s license because he was marked as deceased but the application had no way to resurrect him so this was a failure not in the application but in the design. I’ll write a more detailed blog about that later but one thing I can encourage you to do right now that will make a difference is identifying the errors that are possible in the application and identifying what you want the application to say In the error message. Identify these either in your design such as below or at least document a error table the identifies the error and what the associated error message is.
How will this help? There are two main benefits that I can think of, you might think of others:
- 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. Quite honestly the developer should not be deciding what the error message should say, unless the developer is also the analyst he did have the understanding of the process to determine what to tell the user. Sure some errors are straightforward such as above you missed a value but in other cases with a complex calculation saying the
- The future – You need to think beyond the initial rollout 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 know what happened wrong in my application 6 months from now. When an error occurs although a lot of time is spent trying to understand what caused the error (debugging, testing etc.) , the real impact is the lost productivity by the 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 so after spending hours debugging the application the error was determined to have been caused by a user time zone being set incorrectly. I won’t go into the details as I could spend a day talking about poorly written applications but suffice it to say that it would have been helpful to know where in the application this error was being caused and maybe a more meaningful message.
So in summary, do yourself a favor and document and provide your developer with the error message that should be displayed and know what the possible errors are ahead of time, your applications will be easier to support and you might just have end users solving their own problems.
Later…