Pitching an Application Rewrite – 4 Essential Arguments

A surefire way to ruin any development manager’s week is to use the dreaded r-word. “You know that app the team’s been working on for the last year? Well, we need to rewrite it.”

Many of us, having seen managerial eyes roll back and fists clench, learn to avoid this word at all costs. I worked on a team that pulled off a fairly large rewrite last year, I had a lot of fun doing it, and I’d like to share some tips and lessons learned.

When proposing a major rewrite, you need to demonstrate four things.

1. Establish that there’s a measurable problem with the existing codebase.

Qualitative arguments generally don’t get me very far. On this project, I was able to point to some nice metrics. My strongest ally was the defect backlog. Our team owned a number of similarly-sized applications—this particular application accounted for the overwhelming majority of the defects reported against the team and an obscene percentage of the open defect backlog. Defects were closely monitored in the organization, and a source of pain for my manager and his team, so this really helped.

Next, I took the time to run McCabe complexity tests, which showed this codebase to be off the charts compared to similar applications. I also ran code coverage metrics, which demonstrated that the application was largely untested. While I didn’t need any of these numbers to know the code was painfully bad, these quantitative metrics gave my manager the hard data he needed to fight up the ladder for budget.

2. Show that you have a full understanding of the problem and can be trusted to solve it.

The application I wanted to rewrite was a touchscreen UI for a car stereo. Before making my sales pitch, I was able to spend about four days spiking out an end-to-end implementation of the FM/AM/WM radio features. This was a huge help making the case for the rewrite—it proved with working code that the proposed architecture was sound, that my claims about the time needed for the rewrite were reasonable, and that we could improve on the existing implementation during the rewrite.

We paid special attention during the spike to improve the responsiveness of the application, focus on clean UI updates, and add features from the UI spec that the production implementation had missed. This went a long way towards building trust that we could deliver a simpler architecture, add missing functionality in the process, and do it in the timeframe we were proposing.

I will stress that focusing on clean, responsive UI is very important when doing this sort of spike. My manager couldn’t show “better code” up the management chain, but the audience associated cleaner UI with higher quality software. Another big win for the spike is that we were able to run the same complexity and code coverage metrics against the new implementation and provide hard data to argue that it was a superior solution.

3. Prove that a rewrite is the cheapest option for the organization going forward.

Showing that the old codebase was complex and buggy was a good start. Demonstrating that we could build a simpler architecture was very important too. But what made this project happen was that we were able to show that it was cheaper to rewrite the application than it would be to fix the known bugs and missed features in the existing app.

We used our velocity from the spike to give a fine-grained estimate for the time needed to rewrite the application. We then compared this number to the team’s sizing of the effort required to resolve the outstanding bugs with the old codebase and found that we came out ahead even without having to resort to the argument that we’d save money as additional features were required in the future.

Giving a manager a cheaper way to eliminate a painful, known defect backlog while also reducing their costs down the road? That’s an easy sell.

4. Assure everyone that no deliverables will be put at risk.

The last big item needed to close the deal is assuring everyone that project milestones aren’t going to be put at risk. We were able to demonstrate that our proposed changes could be completed with minimal impact to other applications, that we could validate the new implementation without committing any of the changes to the main build, and that we had a large enough window for QA to fully test the new implementation in the main build between releases.

Putting it All Together

It’s a terrible thing to be in a situation where a rewrite is needed. Some very bad things have happened to result in that situation, and it’s likely there will be a lot of hard work required to dig back out.

But should you find yourself in that spot, I found these steps help make it an easy decision for my manager to approve the rewrite:

1. Provide hard data showing that the existing codebase is unstable.
2. Demonstrate the alternative implementation with working code.
3. Show that it’s cheaper for the organization to address the problem than kick the can down the road.
4. Assure everyone that you won’t be putting the schedule at risk.