Re-engineering: How I Approached an Elephant
Why do developers generally dislike working with legacy software products? Would continuous re-factoring and cleaning up help the clumsy-coded system start a brand-new life? Or could it be better to pluck all business will and create the whole product from scratch but with neat, quality-written code and transparent scale-up capabilities?
My first hardcore business analysis task was about writing a software requirements specification for an online system that was created back in the 1990s. Of-course, it went through some upgrades since then, adopting to the needs of payable customers, but all those upgrades, counting in multiple changes of employees, have only slightly been reducing the technical debt that the system accumulated through years. As a result, it gradually became populated by unnecessary stack of features and funky user experience that, presumably, was hardly seen for a regular user but made the product heavier to accept any improvements and scale in the future.
I was completely unfamiliar with the system, not to mention that it was my first such kind of experience and I first had to invent an optimal way to structure the specification and make it clear and stakeholder-friendly. Another important thing was to streamline the whole process of communicating with stakeholders, and I was rather unaware of this part as I committed to working on this project. Stakeholders had different roles. By roles, I don’t mean their formal roles at the company, but ways how all of stakeholders could share their knowledge about the product to help make my first serious BA writing piece a success. Great people who I had to talk with even more often than with my mom and dad for a couple of the next months were as following:
- At the customer side —Hanna, Product Growth Manager with in-depth understanding of the product, all its UI/UX ins and outs, that are normally taken for granted by a regular user, and
- Jim, Software Engineer with a heavy record of experience in developing the product, excellent knowledge of its back-end logic and functionalities
- at the outsourcing company in Ukraine I’ve been working for — Yaroslav, Software Engineer, who was actively involved in maintaining the product, and for whom I was actually writing that specification, as Yaroslav was supposed to architect the new solution.
Soon Hanna announced that she was going to leave the company, though she was expected to be the key person in leading me through the jungles of the product. Jim appeared to be a more suitable person to help me understand the back-end logic and the admin tools which curated it, so I was quite content about communicating with Jim alone as his competence was sufficient for helping me draft the specification, at least at that beginning stage.
Anyway, Hanna’s leaving was the reason to change our established flow and ask Hanna tell more about the system as a whole — what I little knew at that time, when my writing process was already underway.
During the next couple of calls, as Hanna and Jim were walking me through a bunch of administrative tools, I came to a more solid understanding that the project my top management was so eager to start was immeasurably large, and what I had written up at that moment was just a clumsy attempt to saddle up the huge elephant. I spent the whole evening after our regular call thinking over all arguments that I should bring forward in conversation with our top management the next day — everything for the sake of highlighting the real status quo.
The decision surfaced easily — write up the purpose and any peculiarities about each of administrative tools that were actively used by the client’s internal users, orchestrating UX for the external end user.
Of-course, this decision could have been an unnecessary twist, but it was the right one in many ways due:
- giving a bird-eye view on the whole system
- helping understand what is used and why it is used
- helping map features of certain tools with the logic that they influence
- reflecting usability of menus and features: what is actively used and what is almost abandoned
It took me about nine 1-hour calls during the next three weeks to write a brief overview of all internal tools in use at that moment. Shortly I handed my work in, which, I believe, helped to foster another round of discussions about the necessity and resources for a re-engineering project, now on the executive level. The whole story streamed into a business direction.
It is not a happy ending, it’s a trivial slow work...but who says elephants are fast?
Notes on Starting Things←P R E V I O U S
