This is the second post of a blog series that summarizes the lessons I learned during a technological migration with high uncertainty and complexity. In the previous post, I talked about how I discovered the original problem. In this post, I’ll talk about how I faced the problem.
The details, uncertainty, and complexity kept my progress slow, so I decided to bounce some ideas with my leader because I needed a new plan to start making substantial progress. The goal we set was to get rid of the complexity to start progressing with the development while in the background I continued with the analysis to eventually cover all the business logic.
Transaction Review Page and Analysis Approach
The ASP.NET file had a lot of code that wasn’t even related to the scope of the requirement, which was to migrate the Transaction Review Page, so the first move was to identify the happy path for this feature and its principal components. The following steps were to iterate over and over to migrate more functionality on every iteration until I reached the unusual scenarios.
Choosing a Global Software Development Partner to Accelerate Your Digital Strategy
To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.
The other thing I changed was the analysis approach. In the beginning, I was trying to understand the front-end and the back-end to determine what to render (fields, labels, buttons) and how (when to hide or show the fields, when to show a field as editable or read-only), but since the code was unreadable this approach wasn’t working. I decided that I would render every section and element that I could identify directly in the UI, then I would start adding the logic to hide the elements, then the logic to change them to read-only, and finally the remaining functionalities. With this approach, I didn’t have to dive into the code, at least for the first part I just had to look at the UI, and occasionally confirm some assumptions in the front-end, something that I have never done before.
Variations in UI
With these changes, I started making significant progress. This new way to work without looking at the code was very interesting to me. I logged into the application using different users of different organizations and then opened as many transactions as possible. For every variation that I saw in the UI, I took a screenshot. With this, I identified and documented almost all the components that needed to be built for the UI just by changing the scenario. Having identified the sections, their elements, and their variations allowed me to create and distribute everything in MVC Views and partial Views.
Building the new UI from scratch also gave me the ability to understand the legacy code better, something that I didn’t even think was possible nor wasn’t expecting, especially because I wasn’t looking at it so much. With every iteration I made to add more elements to the UI I had to go deeper into the old code, somehow, I got familiarized with every section and suddenly the legacy code was not so hard to read anymore. And when I looked back to the old Transaction Review Page to compare if I was missing something I realized that the main structure of the HTML that I had developed was very similar to the one in the legacy code, just a lot cleaner and more readable. That surprised me!
What amazed me the most was that in a couple of weeks, I was able to present a demo of the new Transaction Review Page written in ASP.NET MVC. This demo was only the front-end of the feature, it was using dummy data and it didn’t have any logic at all, but it rendered almost every section and element that the feature included.
Different Forms of Functionality