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:

  1. Rewrite the system using developers that provide the best code quality
  2. Rewrite the system using developers that write less-than-ideal code quality
  3. Leave the system as is and just maintain it
  4. 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:

enter image description here

  • 4
    Appeal to the bottom line. Everything you present should be converted into money. If lowering quality means higher discounted profits, so be it. – Deer Hunter Aug 12 '13 at 18:57
  • 1
    Try keeping track of (or creating a report of, if you already have the information) the time (and money) spent maintaining the application. Compare that to the support/maintenance costs of an application that has been primarily managed by the types of developers you are contrasting (along with the time spent creating those components). Also make sure you discuss the expected lifetime of the project; if it's going to become obsolete in 3 months then obviously a major refactor just isn't cost-effective; if it'll still be supported in 10 years, that's relevant. – Servy Aug 12 '13 at 19:11
  • "because I believe #1 provides the best long-term value" - my experience is this rarely provides the best value for the business, are you sure you understand there position accurately (cashflow, risk profile, opportunity assessments). No point trying to get them to save up for a Roll Royce when they need a car to get work to make the money to save up for the Rolls. Best make sure they don't read Joel On Software before your presentation.... – mattnz Aug 13 '13 at 8:23
  • Rewrite is not an option. Refactor, but don't think the existing code is totally worthless. It is the only think that remembers both past decisions and past mistakes. – Jan Hudec Sep 12 '13 at 9:30
  • #5 refactor the system? – Pieter B Sep 12 '13 at 11:29

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  • Great points. Thank you. The hard part is putting those numbers together. – Bob Horn Oct 9 '13 at 19:07
  • Agreed. I found talking to developers was the easiest way to get a gut feel of their time going into it, and that allows costs, delays etc to be calculated. It's always going to be a vague estimate. – SpoonerNZ Oct 10 '13 at 7:54
  • 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.