Inefficiency is easy to measure if you have the right metrics. Consider the example of a sales rep who completes quotes for customers using a legacy system. If you measure that process in time, it may take the rep an hour or two to complete a quote. If you measure that process in clicks, it could be twenty to thirty clicks.
In this case, the time analysis lets you appraise the efficiency of the sales rep’s work day. But that’s a complex time management problem to solve. The clicks, on the other hand, are bound to the application in question and are well-lent to very clear improvement options through redesigning the user experience.
So how do you measure and spot inefficiencies in clicks? First, you’ll need to take both a deep dive look at the source code and then observe how it’s used in real time by the users.
Static Code Analysis
Legacy apps that are maintained over many years give rise to some consistent patterns in their source code. Screens which see the most use often have the most code, the most buttons, and the most fields.
Over many years, these screens accumulate extra bells and whistles to support custom processes and workflows that may no longer be relevant to the business, but which still introduce necessary steps into a the main process.
A static code analysis looks at the code as it exists. This type of analysis lets us zero in on these inefficient culprits in great detail, and allows us to estimate the labor involved with making the clean-up changes to those processes.
Dynamic Code Analysis
A dynamic code analysis is a form of run-time analysis of user behavior as they interact with the application. For all of the buttons, features, and screens inside the app, you only really know which are in use if you track how users get their work done at scale and in real life.
Whereas a static code analysis shows you unnecessary code from old maintenance and upkeep, a dynamic code analysis shows you which of them are most relevant to the business, which processes and features users actually need, and which are important to keep or ditch.
Why use a tool-assisted assessment?
For applications that have lived for more than 10 years, you’re frequently dealing with thousands of lines of source code. Human eyes get tired. The objectivity you need to solve these problems relies on data, and you can get data from a tool-assisted approach. You’re looking for actionable, quantitative, objective data that can be used to make long-term strategic decisions, not snap judgements.
What are the expected outcomes?
With the quantitative data from these analyses, you can outline only the code you want to keep with confidence and detail for a modernization of any sort. Whether that is process improvement, or to support a new front end, you can start from zero knowledge of the code and go directly into actionable steps backed up with data. This approach will move your modernization forward with confidence and efficiency.