We have all been there. Your stomach is growling, yet all of your mental energy is focused on fixing the car in front of you going fifty in the fast lane. When people are hangry (hungry/angry) they may come off irritable and agitated, maybe even point out every little thing that is going wrong, when the issue at hand is as simple as “I am hungry. Feed me!”.
Misdiagnosis happens all the time and can translate into many other facets of life, including software issues, but could you diagnose software issues when it seems like your software is being hangry?
The good news is that with some practice, and skills of observation, anyone can categorize software issues like a pro. This blog will help guide you when encountering software issues. The intention is to lift the many layers that can complicate issues, so that you may accurately, yet simply state the issue you need help with.
Symptoms of software issues are observable by the end user in many forms, such as an error, performance degradation, or a software crash, to name a few. Hopefully, these interruptions prompt users to call to Esri Support and log a case for investigation. At Esri Support, our analysts have a specific skillset. Few of us are generalists, and this structure is designed to provide our customers with elite technical support…in other words, we don’t use scripts.
Why is this important? One of the first steps to logging a case with Esri Support is providing a description of the issue, which will be used to form a subject line in the case. These subject lines can be altered as more knowledge is gained on the issue through investigation, but this initial subject line is big factor in determining which analyst owns the case first.
Determining the overall symptom helps guide the triage process and the lifetime of the case. Let’s explore these symptoms in more detail.
Error messages will stop us in our tracks. Sometimes the messages are very useful, and tell us exactly what we need to know to proceed, sometimes not so much. When users encounter errors we always request a screenshot of the error and the workflow (clicks) leading up to the error. For example, “Error: invalid coordinate system identifier” is seen when adding data from an Oracle enterprise geodatabase into ArcMap.
2. Performance degradation:
Personally, this is the most frustrating issue to encounter. There is no error; instead, the process is slow, and the spinning hour glass doesn’t tell you when you can expect performance to return. When performance cases come to my desk, I first gauge the slowness, because “slowness” is a relative term, and something that is slow in one environment may be optimal in another. The symptom here isn’t just performance, but specifically performance degradation. In other words, there was a more optimal performance, which has now degraded.
Symptoms of slow performance can be caused by many things including workflows, overloaded resources, and software compatibility to name a few. To get started troubleshooting it is always helpful to have a comparison case available for investigation. If you believe you are seeing slowness in software, first ask yourself ‘this is slow compared to what?”
For example, “using ArcMap 10.1 sp1 to do the same workflow on the same data takes 1 seconds, while using ArcMap 10.5.1 takes 20 seconds”, or “Previewing feature class A in ArcCatalog takes 1 second, while previewing feature class B takes 20 seconds. Both features are stored in the same enterprise geodatabase”.
These examples give us a “fast” example and a “slow” example that can be compared to each other. Notice in these examples that there is only one difference in the workflows, giving us controlled variables and a single dependent variable to review…right, like scientists.
3. Unexpected results:
This symptom, like performance, will not produce an error, but unlike performance symptoms, these processes will complete, seemingly successful. However, when the results are analyzed they are incorrect or incomplete. Unexpected results can also take the form of tools being disabled, or grayed out.
For example, “I open ArcCatalog to enable Editor Tracking on my feature class, but Enable Editor Tracking is grayed out”, or “I created a replica of my U.S. States feature class, but only 48 of the states were replicated into the child geodatabase”.
Most of the time unexpected results stem from a workflow issue. Some setting that needed to be turned on for this tool to work was not turned on, or properties/constraints on this data caused the unexpected results. In the first example above the connection must be made as the data owner to enable Editor Tracking. Any other user connection will see the Editor Tracker option grayed out. The second example, where not all data has been replicated, may be due to filters placed on the data being replicated, or relationship classes enforcing database referential integrity.
Click, click boom goes the dynamite. There is no error. The best you can do is re-open the software and try again. Esri considers all crashes a bug. We want our software to give you a meaningful error that will help you complete your work. Crashes occur when the software encounters an argument that it doesn’t know how to resolve. Always report crashes to Esri Support so we can ensure our software understands how to handle these situations.
Software issues can be complex, can employ multiple technologies that require different levels of expertise on many different subjects. These issues can be more approachable by answering the question, “What did I observe during my daily work that prompted me to request help”? While there are always exceptions, 90% of the time I can start answering that question with one, or more, of the symptoms discussed in this blog. I hope this helps brighten up the perceived darkness around software issues, and as always, give us a call if you encounter any of these issues, or just have questions for us.