A Two-Perspective Approach to Reverse Engineering by Julian Flaks
Opinions are divided on reverse engineering a legacy solution; some point to all the challenges and declare it the wrong approach, while others recognize that sometimes that is the requirement, and what remains is to mitigate the risks and apply the best methodologies towards getting the job done.
One methodology EQengineered has found to be especially effective is a “two-perspective” approach. In estimation, one can benefit from combining a top-down and bottom-up approach (one goes broad, the other builds up the details). Similarly, deconstructing the problem of reverse engineering can be thought of via two parallel perspectives.
Perspective 1: The Customer Functionality
In the first perspective, EQengineered looks at it first from the customer’s point of view: what jobs are they accomplishing, and by extension, what is the software ultimately responsible for. This is the most obvious breakdown since it also focuses on who is affected when a legacy system either falls into disrepair or is decommissioned.
Some tips for this approach:
Make sure you know all the possible customers. Sometimes a screen seems unused, but behind the scenes there is activity involving a user not on anyone’s radar. Use access logs, data facts and organizational awareness to try to fill in the picture.
Connect the systems. If outputs lead to other systems, then ask what else needs to be updated or recreated once a new solution is put in place.
Find behaviors that exist outside the system: manual edits and jobs, Excel manipulations and handwritten notes may be as central as what the developers can see.
Perspective 2: Dismantling the Clockwork
The best way to picture the bottom-up version is the dismantling of a watch into lots of pieces. For every piece of code, schema, datapoint, stored procedure or pipeline, ask “where does this go?” and “what is the purpose of this?”
This is a frustrating but enlightening process. The frustration comes not just in its complication, but also in the fact that at the end, just as with putting something back together, you may genuinely have parts with no purpose. But when you see a part, begin by assuming it does something and you might just be blind to a requirement.
It is useful to allow time for such hunts within the more routine development tasks, and to make tickets specifically to explain or discount leftover pieces. These should be time-boxed for efficiency and for the sanity of whoever handles the ticket, but their role in mitigating risks and mistakes can be huge.
When everything is accounted for, there will be more empowerment of the user-centric analysis, because details the user may be unaware of will have emerged, along with clues that may explain oddities in the workflow or lead re-implementation into different directions.
"Can we improve this while refactoring it please?”
Depending on what has happened in the years since it was developed, some portions of an application may no longer be useful, and others may be inadequate. Typically it may be the opportunity when the user sees a chance for improvements and when development teams feel the rejuvenating opportunity to better serve the business or customers. This can be a pivotal moment for workflows and use cases; developers are at the height of their understanding, and testing will be making sure of impacts of changes. However, the urge to effect change should be tempered by remembering the following:
Reverse engineering is more perilous than green field. A Big Bang cutover may have to take the place of incremental feature additions, and requirements may silently exist in how the system performs outside any customer’s awareness.
Even modest refactors are more successful when the refactor is performed separately from functionality changes.
When approaching legacy systems, there may be no individual or team with a full understanding of the processes and systems touched upon by an application.
When improvements are identified but they present risks, the capture of the information and opportunity is vital. Agile backlogs apply to reverse engineered applications just as much as to new applications, and the lifeblood of a successful Minimum Viable Product (MVP) is just as necessary.
Summary
Through the exploration of both the customer-centric and bottom-up perspectives, the team will develop a detailed understanding of the solution’s function as well as how the intricacies of implementation may play an unseen role in the end-user experience.
Above all, when the needs of reverse engineering presents itself in modernization, it is usually because a high value business process requires some serious love and attention. Risk mitigation has to be a priority, and systematically looking at the same problem from more than one side is a good analytical measure. Higher understanding always paves the way for a better-informed reimplementation strategy.