This is the second post of a blog series which 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.
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.
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.
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.
From here the work became more manageable and I kept updating my planning. The following steps were obvious, I just continued adding more functionality like reading the information of the transaction from the database and populating the elements, adding the functionality to hide/show elements, identifying which JavaScript methods and C# methods I had to migrate, which methods I could reuse, which methods I had to decouple from the data and view logic and create again, and so on.
