We have a legacy classic ASP application that's been around since 2001. It badly needs to be re-written, but it's working fine from an end user perspective. The reason I feel like a rewrite is necessary is that when we need to update it (which is admittedly not that often) then it takes forever to go through all the spaghetti code and fix problems. Also, adding new features is also a pain since it was architect-ed and coded badly. I've run cost analysis for them on maintenance but they are willing to spend more for the small maintenance jobs than a rewrite. Any suggestions on convincing them otherwise?
I believe there's two factors you should consider that you at least didn't cover in your Q. Let me define these as I use them, then I'll get onto the business of answering your Q.
Risk is probably obvious: The chance that they pile a mountain of money into something that goes nowhere. Risk is compounded by what Brooks called "Second System Effect" and the rest of us call "Gold Plating". Every rebuild I've seen carries risk from people who add every feature they didn't add the first time around.
Opportunity Cost in this context is the cost associated with you rewriting functionality that from the business perspective was working fine. It is Opportunity Cost because it means you don't have the opportunity to add features.
To sell something that is purely a refactor is hard because Risk and Opportunity Cost both have money attached to them from a decision making perspective. What I generally recommend is that instead of selling a rewrite of the system, you sell an "improve as you go" at a component level. It costs more because you have to build adapters/facades/proxies, but it's less risky and easier to sell. I've been there on the "we need to rebuild it all" and it just doesn't go well.
And here's the rub: Over time, all systems turn into garbage unless you are disciplined enough to keep them from doing so.
Which leaves me with this question back to you: If you can't sell them, or even your team, on doing the right thing day to day, what makes you think you can actually see a rewrite through?
It really does take some serious introspection to answer that question honestly. Sometimes you've been handed a system from someone who had no clue. Sometimes you've been handed a system by someone who started with the best of intentions and on the right foot but got compromised by a poor corporate culture along the way. If you can't tell which it is, you need to find out soon!
Here are some ideas, all of which I've done more than once.
Some of the best things I've ever written started off as stealth projects. Things that people said were not possible. Another one I hear a lot is, "people smarter than you have tried that and failed." When you show up with a compelling proof of concept, it pretty much decimates those arguments.
I can't tell you how many times people have denied letting me work on a project, rebuffing every reasonable argument, just hearing none of it. Then I show them a demo, and suddenly they think the project is a great idea. But do be careful: the more you needle someone and the more they insist the answer is no, you need to be careful: they have to have an honorable way of changing their mind without resenting you for it or feeling wrong. So be diplomatic, ideally try to make them think it was their idea. or have a good relationship with them, alternatively.
The key to a great demo is planning. Don't start by thinking of what the product should be. Start by thinking of what the most awesome demo would be like. You have to do enough engineering that your demo isn't just pure vaporware, but what you want to implement first is whatever it'll take to make that demo rock their socks.
For example, we had this huge body of code written in PHP one place I worked. My team and I wanted to use Python, but management didn't want to fund us to do that. We started adding new functions using a Python webservice, and using curl to access those from PHP. It wasn't a total rewrite, but once we built the facilities to make it easy to integrate the codebases we had established a beachhead, we were able to move the rest of it forward more easily from there. I've done the same thing with doggy legacy systems in languages like COBOL and RPG/3, calling out to Java.
Think extremely carefully before any rewrite. Read Joel Spolsky's blog post,
I have had the opportunity for a complete rewrite twice (different jobs).
The first was a rather small app. The rewrite was estimated to take two programmers six months. We made the deadline and the customer was very happy. Unfortunately despite the demand, marketing dropped the app so the effort was wasted.
The second was the main app of a small company. The rewrite was completely underestimated and almost ruined the company. In the end the project was a succes.
The problem with rewrites is that it does not add any functionality to the app. Which means it is hard to sell. So it is better to rewrite small pieces at each time. Refactoring++.
Don't re-write - the risks and costs are too high for your business. See the Joel Spolsky article referenced by @Grokus for reasons why.
I proffer an alternative option - a combination of refactoring the code that is suitable plus the introduction of a complementary technology alongside. For example, start writing new pages in ASP.NET, gradually migrating more and more code into the .NET world. We've done this successfully - new features are a great opportunity to do this, but simpler parts of the system that can be migrated quickly are also candidates. It may be necessary to concoct some level of abstraction or kind of bridging system (add an API layer to the 'old' system) to get there.
Only you can make the call whether to go for MVC + AJAX, MVC + SilverLight/Flash or similar, but you don't have to park one thing before going forward.
Yes, there'll be some pain and confusion along the way, but you'll have a shippable product the whole time, rather than a long, long, long time 'in development' with an established product becoming obsolete and losing market share to competitors.
Do you mean sell it to your business, as in convincing managers to go for it? There's no magic trick, unfortunately, to make managers who view everything in the short term to recognize long term problems. Especially if they arent technical, they may not appreciate the technical reasons for such a thing. The single best thing to do is what you've already done - demonstrate that its the right thing financially. If they dont go for it, there's not much you can do other than sit back and watch things implode.
On the other hand, if you mean how do you sell it to a customer who is a business, thats easy. Re-write the thing, and tell them that if they want feature X, they need to use the new system. Sometimes, to help a customer, you need a little tough love.
First, create a category for typical changes in terms of SLOC (and function points if it involves changes to UI elements.)
Then look at previous code changes and see where they fit in the category model described above.
Do the same for new features (that is, treat code changes and new features differently unless a new feature involves significant change/cost on the existing code base.) If integrating a new feature is trivial, separate it from code changes. If its integration with existing code base is significantly costly, lump it with the code changes.
Then, for each categorized code change (or new feature), determine 1) how long it took to complete, 2) how long was it supposed to take to complete, 3) how many people were actually involved in the completion, and 4) how many people were initially thought to be required for its completion.
So now you should have a tabular presentation of delivered artifacts (code changes and new features), each with columns indicating estimated and actual resources (hours, people) consumed.
You can then assume a ballpark average engineer salary/hour (say $40/hr). Multiply that by 2 to indicate total cost of engineer/hour (an estimation of hourly salary, electricity, office amenities and rental, etc.) It doesn't have to be accurate, just realistic enough.
For each delivered artifact A, you can compute the following:
With these relations (which must be based on actual code changes or new items... otherwise they are meaningless), you can can calculate (per category size), what is the % of a code change of that size to deviate from the estimated size (a % of failure), the approximate cost as well as the % the code change might actually reach a max. cost.
Chances are the % for maximally deviating from the estimated (minimal) cost resembles more and more a exponential distributation the larger the code change is.
With that date, you can tell your customer the following:
Now, this is key. You have to do the same computations for new requests (the type whose integration with the old code base involves not-significant changes on the later).
If you find that the estimated, approx and max costs for new requests of a given size is (hopefully) significantly less than the costs of old codebase changes of the same size, THEN you have an argument for a code rewrite. You have given sufficient evidence that the old code base is expensive to change compared to changes of the same magnitude in new code.
But if the costs of new code requests do not greatly diverge from old code changes of the same magnitude, you will have a hard time justifying a code rewrite (and it might indicate that the problems are not only to the code base, but also in your development practices.)
If at all possible do what you can to make the application better as it is right now.
If you are dissatisfied about the documentation, then after you have spent time figuring things out WRITE THEM DOWN for the next maintainence session. Frequently when you see a code base for the first time, just a short lists of "therefores" (to answer the whys the code cannot) can help immensely understanding what goes on.
Figure out a way to do it a bit at a time.
If you try to rewrite the whole thing from scratch, you'll probably never release it.
If your bite size chunks are small enough, you may not even need to sell this to the business at all: you may be able to simply go ahead as you implement new features.