This is the first post of a blog series which summarizes the lessons I learned during a technological migration with high uncertainty and complexity. In this post, I’ll talk about how I discovered a problem.

 

Recently, during a migration from a client’s project, I had the opportunity to apply and improve my skill set: technical, analytical, managemental, communicational, and emotional, all at once. At some point, I felt that I was facing a dead end, but I learned to manage the situation, communicate with the team, change the direction, and provide a solution elegantly. This blog series is my attempt to summarize what I learned. I hope this reading provides you with a new perspective when you either perform a technological migration or face a project with high uncertainty and complexity.

 

Content

Part 1: Discovering the problem
Part 2: Facing the problem
Part 3: Flags and Lessons

 

The client had a bunch of applications, services, databases, and other things supporting their business. Most of their code had already been migrated and updated to newer technologies, they also had implemented newer frameworks and the bests design patterns, but they also had a couple of legacy applications that were still in use and had been modified and patched by many hands. That was the project I had to work on.

 

I was given a huge Visual Studio solution where several applications shared lots of business logic in the back-end and the front-end, it was a legacy monolith in which no one in the team was fully an expert. It also had a mixture of technologies, frameworks, and design patterns (or anti-patterns) created from the 2000s to now. That was not all; some sections of the application were also coded with over-engineering, tasks that should have been simple or direct were hidden under unnecessary complexity, and many of the methods had multiple purposes. A classic spaghetti code.

 

I was assigned to a task that seemed very easy at the beginning and during almost all the project I was feeling more challenged than I expected. The client gave me a “simple” requirement: there was an existing page of the web application (I’ll call it the Transaction Review Page) that needed to be migrated from ASP.Net Web Forms to ASP.NET MVC and it was supposed to keep all the existing functionality. That was the actual description of the requirement.

 

The Transaction Review Page was a step in a workflow of the business where certain users with certain privileges could access it to check some information, validate that everything is okay, enter some additional information if needed, and submit it to the following step in the workflow.

 

First, I got a walkthrough from a tester on the team that was familiarized with the page from the user’s perspective. He explained to me the functionality of the page and showed me the main sections and some of the UI variations he knew the page had. After the walkthrough, I started playing with the page. I opened the Transaction Review Page with different transactions and discovered more UI variations between transactions: some elements appeared or disappeared (like inputs, dropdowns, buttons, tables, or even entire sections), some fields changed between editable or read-only, and sometimes the user had access to specific functionality based on who knows what.

 

In my first analysis of the code, I realized that the ASP.NET file for the Transaction Review Page didn’t have a single responsibility, it was reused to give functionality to different sections of the web application that weren’t even related. The front-end was hard to read because the page was full of ASP.NET User Controls with nested user controls. I also found that the actions the user can perform and the appearance of the page change depending on variables such as the type of user that is logged in, the user’s privileges, the status of the transaction, the type of transaction, the step of the workflow, the page that redirected to this page, configurations on the database for almost every field, and so on.

 

The number of variables that change how things work on the page was overwhelming. On top of that, the business logic was tightly coupled with the data access logic and the view logic making it difficult to understand the front-end and the back-end of the application. I couldn’t keep a straight line when analyzing how or what to render in the UI. I started realizing the amount of uncertainty and complexity of the requirement and I think no one was aware of that until I brought it up to the team.

 

Continue reading

Managing the uncertainty and complexity in Software Development – Facing the problem (part 2/3)