My experience working on mPharma’s legacy codebase — Pestle

Photo by: Joshua Aragon from Unsplash

When I received the call from our VP of Engineering stating that the BLD squad needed a Frontend Engineer to work on Pestle and that I am a good fit for it, like most developers, I wasn’t that excited because this meant that I would need to go through the phase of taking over an old codebase and work on a project that is totally new to me. Little did I know that it was going to give such benefits that I hardly saw coming.

Before I proceed, let me give a brief background on the application and what solution it is providing.

What is Pestle?

Pestle is one of the first applications built by mPharma with the sole purpose of helping the Supply Chain team handle the supply chain processes. Pestle keeps track of everything — from when the supplier warehouse (the facilities that supply mPharma with drugs) receives a purchase order, to when it gets to the mPharma warehouse, then to the facilities that make purchases from mPharma.

What I learnt from working on Pestle

Not long after, I realised that most of my team members from the new squad also had little or no idea of what we were getting ourselves into because none of us on the team had joined mPharma when the application was developed and it hasn’t been maintained for a while. I felt relieved as I wasn’t alone — we would all go through this learning phase together.

After a series of meetings my PM had with other PMs, my team members and I got some background on what the application was about, and also the improvements we needed to make within the application to help our warehouse team. I took the great leap of faith afterwards by looking at the codebase. All the components were written as class components in this era when functional components are widely used and I just wasn’t comfortable with a bunch of things.

We successfully worked on the new improvements and features and got them ready to be shipped. Before we got to this point, I thought that maintaining the Pestle application was going to be a herculean task, but I have come to realise that it actually contributed positively to my journey. I can share this with anyone who is currently maintaining an old codebase or encourage you that it isn’t bad after all.

These are some things I learnt from this experience:

1. I refactored a lot of things: Having worked on other mPharma applications like Bloom, I didn’t get the opportunity to improve or optimise the build or CI processes, but Pestle gave me the opportunity as I had to make a lot of changes and with some help, I have a higher grasp of how things work with that regard. Apart from the CI processes, I also abstracted duplicated code and rewrote some code to make it more readable.
2. I debugged a lot: I actually spent more time debugging than adding new features. This is because I didn’t want to continue using class components, and also because I wanted to upgrade the packages. Hence, I made a lot of changes that in one way or the other also contributed to things breaking. Debugging helped my analysis skills, taught me how some things work and helped me reduce unused or distracting code. If you need more reasons why you should debug more, read how debugging can make you a better developer.
3. I understood the business side of the application: With the help of my PM and chapter lead answering my questions and bringing to light why we have certain features or why and how certain features are the way they are, I understood the purpose of the application and how the business is affected by the improvements we make on the application. What got me more intrigued was when our PM organised a meeting with the QA, some select members of the Global and Zambian Supply chain team members and I to do a demo of the features and improvements they would see once we ship the changes made. They were apt to ask, commend, raise concerns and even requested further improvements. This gave me an experiential understanding that I am actually making a change with my code which was a really great experience.
4. I got the experience of working on an old codebase: The last benefit was the experience itself. In the web development industry, things move too fast, which also means that it’s hard to find an old front-end application that is still being used and maintained. This experience isn’t easily attainable, and hence I am grateful to get the chance to experience it.

Conclusion

Working on an old codebase isn’t that bad and could be a great opportunity to learn and improve your skills. It’s even better when you are surrounded by great engineers who are readily available to help you when you need it.