Recently, we got a project that is built on a popular PHP framework. We soon realized that the codebase wasn’t compatible with the latest framework version and needed to be updated. The project had come to us for a new feature with fresh requirements. That time, we can’t say to our client that the platform is dying and needs to be updated first. But not mentioning it wouldn’t have been good either. We updated our client with the situation saying that we can work on the new feature but the future doesn’t look very promising if the platform isn’t updated soon. The client understood the concern and agreed to come back to the update soon.

The system setup was another pain. Our machines switched back to the initial versions of dependencies where other projects didn’t work (that was a learning for us as well though as we should isolate our projects’ environments). Finally, after the setup, we started working on the feature and man, the codebase was so confusing. It wasn’t just the old framework version. The code wasn’t optimized and didn’t use that framework efficiently. It was unreadable and taking up to thousands of lines per file. This wasn’t good. We knew we were diving into an area nothing less than hell. And there might not be a way back. We dived anyway keeping the larger picture in our mind.

We were using newer frameworks and most of the basic things came in-built. But here it was different. As we dived more into the code, we always wanted to fix something wrong, an inefficient piece of code, correct indentation and making code readable. But that would be out of projects scope. The best thing was to skip. Aah, that itch! We also realized that some of the features we can already utilize but they weren’t optimized. We had to write our code in such a way that if changes for optimization happen later, our code shouldn’t get affected. That was an extra effort and precaution that we had to take.

The delivery timeline extended as we dived more into the code. After a few days, we had the estimation ready. We finished the piece in time. Not completely satisfied with the approach was it was the best way at that time. The story would have been different if we just dived and cleaned up the mess. But it wouldn’t have made sense to our client since this application was running fine without the code optimization. And it was best for the business also. From the client’s perspective, it wasn’t adding any value to the application. Which was somewhat true. We proposed our client that we can do some optimizations in each new module in the areas the module depends upon. This won’t have a huge impact on the business and the system will gradually start improving. Though a one-time complete system update would be required, it is not needed yet.