Getting support for a software system rewrite?

Question

We have a web site that was written five years ago by people that didn't know what they were doing. (I feel justified in saying that because I was one of them.) The resulting site was (and is) slow, unreliable, frequently crash-prone, and a maintenance nightmare - the smallest change often requires refactoring or rewriting large chunks of code. Additionally, we are stuck using a javascript library (Dojo 1.4) which is so old that it's not even supported anymore.

Now, with five years' experience and a much better grasp of the site's requirements, the team I am part of is in a great position to write a new site from scratch, using current technology and fixing a number of fundamental flaws in the design.

Unfortunately, every time I bring up this subject I am told two things by fellow team members:

1. Shut up, we'll handle this piecemeal as things break.
2. If you have any questions, see point 1.

The only thing I can deduce is that my fellow team members view this ongoing maintenance nightmare as "job security" - no one else could keep this code running, so they basically have employment for life.

There are several problems with this:

First, ethically speaking, I hate doing crummy work just to pad my timecard.

Second, everyone hates the site as it is - it is a constant source of pain for everyone who uses it.

Third and finally, my suspicion is if we don't step up and make the site radically better, we will one day all get fired and people will be brought in who can do this right.

What is the best way to advocate or lobby management for a complete rewrite of this system before some disaster strikes?

Answer 1

Like Mark Phillips commented, this is a question of initiating a project.

First, understand that when initiating a project, it's all about value. If people generally feel that the system does its job, then you will have your work cut out for you to push the project on technical concerns.

If there are functionality sets or flows that cause real business problems, focus on replacing those. A project to replace a problematic "Click to Chat" feature set is going to be a lot easier to get support for than a whole overhaul - especially if it causes tangible business problems, like it takes so long to connect the user with someone that they leave, potentially taking sales with them.

If you have one or two of those sorts of things, pick someone with a lot of clout if you don't have the pull in the org and explain how a small project like this will have a real business impact. Keep it as small as is reasonable and as tangible as possible. It'll be a lot easier for those in charge of picking projects to understand and increase your chances of getting it through.

Assuming that goes through and you can do a rip and replace on that work, the business will be able to see the value it generates and pitching the next piece will be that much easier.

Tackling the technical challenges of working through a redo this way can be difficult, but I've seen teams do it and it beats the heck out of being told no until the day the whole thing falls apart and it becomes a disaster.

Answer 2

What is the best way to advocate or lobby management for a complete rewrite of this system before some disaster strikes?

It's all about ROI.

• Calculate how much time your development team currently spends fixing this website of horror. (i.e. 10 hours/week) (CurrentDevTime)
• Add in how much time people waste using the product, because there are certain "unfixable" issues (if any). (Waste)
• Create a target work reduction percentage... i.e. I think if I rewrite this it will take 40% less time to keep it functional. (ReductionPercent)
• Assume you can mitigate all unfixable problems in your new architecture (you will architect it so that this is true).
• Estimate how long this software will remain in use after the rewrite. (UseTime)
• Estimate how long it will take to rewrite (WriteTime)...

So, if (CurrentDevTime * UseTime + Waste) - (CurrentDevTime * (1 - ReductionPercent) * UseTime) > WriteTime, then you have a positive ROI.

All you have to do then is remind them of opportunity cost too... all that time you spend on this is keeping your from developing other stuff that will also save people time and energy.

If you want, you can also estimate WriteTime as not a constant, but as increasing as time goes on. Then you show them the trap... ultimately there will not be a point at which it is too expensive to change, but also wastes massive amounts of time and resources to maintain. The longer this goes on, the worse it will be.

People who aren't techs don't care about the tech, really. Translate it into dollars and cents and man-hours (which, to them, are also dollars and cents, really).