A project upgrade that I am responsible for is going live today! This was over a year of work. So many off hour ah-ha! moments and countless sleepless nights thinking, How can I make this work? I couldn’t have completed it without the support and effort of my team and management. They helped to bring it to the finish line and I’m thankful for them. I’m also very grateful for the opportunity to do (and complete) this project. It was rewarding and fulfilling work.

This project didn’t go as planned as it was slated to be an upgrade of the framework it was written in, but it wound up being much more. This application is solid and well built. Yet, no matter how strong the application is, father time always wins.

Many stable and solid applications fall into the “if it ain’t broke, don’t fix it” adage. I’ve found myself saying this with a lot of applications that I’ve worked on in the past. As solid as this application is, it deserves that level of respect that the adage brings with it. Why fix something that works?

Doing an upgrade like this prepares the product for the future. Yet it doesn’t offer the user anything tangible. It’s understandable why these types of upgrades are a challenge to prioritize. But to management’s credit, they did.

Software is meant to be updated. But in my experience, it is never a question of if it will be updated; it’s always a matter of when it will be updated or rewritten. This experience will be my case study for the question: “Is updating incrementally worth the cost now?” My answer would be to ask a slightly different question: “When you have to update it, what will it cost then?”