I’m responsible for creating a presentation to management that details how a system should be refactored or rewritten. We have an existing system that has had production failures and the code base is not in a desirable state.
Here are the current possible options:
- Rewrite the system using developers that provide the best code quality
- Rewrite the system using developers that write less-than-ideal code quality
- Leave the system as is and just maintain it
- Rewrite the system using cheaper labor on the other side of the world
The issue isn’t which one to choose, because I believe #1 provides the best long-term value to the business. The issue is how to present this to management so they understand the costs to each shortcut they take from #1.
For example, I would start with presenting #1… then what? My original idea is to somehow show each shortcut and what that means in terms of long-term cost/benefit. So, perhaps management wants to use cheaper labor. I need to show what that does to quality, time, etc. How do I show that? Perhaps management wants to use a hybrid of the above options. How do I show that? There could be 20 different permutations of the above options, and I’d like to show that if they take the short-term approach of low-cost everything, what that eventually means to the quality of the product.
Are there graphs for this type of thing? A recommended approach? I could just start typing, but I don’t want management’s eyes to glaze over from too many words. Hope that all makes sense.
An idea is to present something like this for each option:
5
The business is interested in time, money, and emotion (depending on the product). I dealt with a similar problem, and presented it from a few different perspectives:
-
It is costing us ‘X’ per month to maintain TerribleApp, adding no value to the business. If we spent ‘X’ up front, this project would pay itself off in ‘X’ time, and be much more reliable, easier to use, etc.
-
TerribleApp is taking up ‘X%’ of the development teams time, which means we are that much slower getting our new projects, such as AwesomeApp out the door.
-
Remember the last time TerribleApp crashed catastrophically and took ‘X’ days to get back up and running? This caused dissatisfaction to all our customers, reflected the organisation badly, applied pressure to the executives and entire IT team, caused John to leave the organisation etc, and potentially lost us X% market share, who are less likely to by AwesomeApp when we release it. These outages will recur no matter how much work we do supporting this application, and will continue to damage our brand.
-
Our development team are of a much higher quality than those that built TerribleApp, as you can see from the recently released GreatApp. If it is built by a good team who are trusted and know what they are doing, the risk of TerribleApp2.0 (might want to rename this) suffering the same fate is very low. If we outsource or use unknown developers we increase the risk of failure, or high maintenance costs again. If it is built off-shore project management will be much more expensive from the local contact, and the risk of another failure is higher.
2
- First estimate the effort required to refactor/rewriting the code.
- Then find out the cost implications of all 4 options.
- Find out the loss made due to production outages of the legacy system
and then compare the benefit each approach would give comparing it with potential loss if there is a produciton outage.
You can emphasise point 2 and 3 are not something you would recommend and you can concentrate on point 1 and 4 of your presentation
Give pros and cons of both approaches and try to keep you presentation objective.
Really speaking management will be more interested in cost-benefit ratio, rather than just cost. IF the low cost offshore developers are going to fix your problem for cheap why not use them.