Let it go - Phasing out old Code

Having a successful product is the expectation of every product manager. Now, we all know success is not promised to every product out there. However; when we do have a successful product in the market we get some new responsibilities added to our docket. One of those most important responsibilities is code maintenance and a big aspect of code maintenance is phasing out old code.

Phasing out old code may seem like a task only for development, but like anything Agile related, it’s actually the responsibility of the entire team. The iterative nature of Agile development can sometimes lead to sections of old unused code that can’t easily be cleaned up during an MVP sprint. Now please don’t use this as a rule to keep messy unused code in your builds. But if some updates are left behind don’t be alarmed, just know it’s important to tackle this before things get out of hand. Imagine building a tower on broken and uneven levels of bricks. You get the picture.

So how should the whole team pitch in? I’m glad you asked.

• Product Managers should be aware that code cleanup is just as important as delivering new features and should manage stakeholder expectations accordingly. I know it can seem daunting to deliver the news to a stakeholder that the next MVP will contain updates they didn’t request, nor do they care about but they will forgive you.

• Stakeholders should never consider internal application updates as needless or time consuming. Although they may not have user functionality they will make your new features rock solid by eliminating useless code. Remember the example of the building the tower on the broken bricks? Again you get the picture.

• Project Managers may not always be able to dedicate an entire sprint to a full application cleanup, but there are methods to sneaking these updates into each sprint. Staggering these efforts to sections of code not impacted by new feature development is one way to get it done. Ironically the opposite works as well by adding buffer into the schedule for the cleanup required in a new feature releases. Both approaches require input from your developers to know what code needs to be addressed.

• Developers should communicate to business analysts and project managers what areas of the code need cleanup. Don’t be afraid to speak up when you find obsolete, unused, even poorly written code, especially if it’s your own. Your team will thank you in the end.

• Business Analysts should also take these gaps in new feature design to clean up technical specifications and user stories. Like developers business analysts are keeping technical specifications up to date and can often ask for a code updates but not have the time to update the spec.

• Testing also gets to join in on the fun because code cleanup should still go through rigorous testing to ensure no updates adversely impact the applications functionality.

So what am I saying? Overall code cleanup isn’t the corvette of a release but there is an instant gratification in knowing that old obsolete line of code written to prove that a legacy api call happened in 2 seconds or less is gone!