In the world of software development, maintaining and upgrading outdated codebases is a challenge. That’s the reason why I chose this blog post titled “Ask an Expert: Upgrade Outdated Codebase” by the Increment team. Given that this topic directly relates to when class CS348 did an gitpod assignment on software maintenance. I’ve seen many other peers recommend this article as it offers expert advice on how to approach and successfully execute upgrades to aging codebases, ensuring they remain functional and relevant. When you’re faced with these questions, should you make the change, when should you make the change, finally how should you make the change. 

The Increment blog post provides 3 optional & practical strategies for modernizing outdated codebases. 1. A Big Bang Rewrite (changing the codebase from scratch and cutting over all users in a single conversion). But of course, this has its cons, such as being time-consuming and not seeing the process unless it’s all finished. 2. Tack the New onto the Old. The second option is to add new features built with new technology to the existing codebase. However, it’s not like you can just add in a new feature with the old and not touch up the old feature at all.  Outdated features are outdated for a reason, there has to be a balance. 3. A Hybrid Approach. Why choose one, when you can do both? Rewriting your entire codebase is a drastic and often un-recommended move. Adding new features to an old codebase is usually more manageable but can lead to serious issues. Therefore, finding the in-between. This option requires changing out the whole of your old code. But unlike the first option, the rewrite should be spread out over a period of time to minimize technical debt and financial cost. However, all these solutions have side effects, including this one. While you are updating, the technology could continue to advance and you’re left trying to catch up all over again or the specifics/goal changing as you are.

I really appreciate how the creator goes about explain their reasoning. I personally follow the motto: if it isn’t broken, don’t change it. But the way the blog presents actionable advice from industry experts, which is crucial for understanding the best practices in managing and modernizing legacy systems. Made me shift my thoughts a little. Change it before it becomes broken. As quoted from the blog, “it’s probably your last chance to fix the technology before it becomes irreparably broken.” 

Given that this topic directly relates to our course material on software maintenance and evolution, the insights provided are both relevant and timely. One key takeaway from the article is the importance of documenting the existing codebase before initiating any upgrades. Maybe even make another copy, it would be terrible to find out your “updates” ended up making things worse than before you decided to change it. This is definitely something I can expect to apply to future practices. 

I have learned a lot from this blog and for further reading, you can access the original blog post here.

From the blog SoftwareDiary by Oanh Nguyen and used with permission of the author. All other rights reserved by the author.