3

Old application that is used by 50-60.000 paying customers. Company is several hundred people big. Application has a lot of business critical code (30% of all code) written in classic asp. Application has a lot more .net code. Application has a COM+ bridge for enabling asp to "talk" to .net Organization lacks some/a lot knowledge on what is causing the 10-20% server-reset per day (might be due to COM+ ?) There is no red line through the application; no architecture, no real patterns etc. The application has been like this for at least 5 years. The asp code base is increasing, slowly but certainly.

I have read refactoring stories and I have knowledge on why you some of the times should not re-write a system.

I would love for the old asp code to vanish as well as the COM+ component. But the pain is that no one really knows what is going on inside the asp classic code and the attitude inside all the teams are "this is just how it is".

Down the line, this causes a lot of other issues like recruiting, dev effeciency, business needs that cannot be met, scale etc.

With these little facts, does that justify a re-write of the asp code and the removal of the COM+ component ?

How would you go about it ?

marked as duplicate by GlenH7, gnat, user40980, user22815, Bart van Ingen Schenau Aug 26 '14 at 7:42

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 3
    Not really the answer you may be looking for, but as long as "all teams" do not see a problem there, you may as well be fighting against windmills. – Frank Aug 25 '14 at 10:54
  • 3
    I think it is clear that your company's project is heading towards an eventual brick wall. Maybe it is not yet a problem, and now would be the time to act, though until everyone is onboard, it is a lost cause. Focus on finding enough evidence to show why this is going to be very bad in 5 years time. – Neil Aug 25 '14 at 11:04
  • As a fellow programmer, these are the things I inquire about during every job interview. If I get a sense of something like this, I get out of there asap. The effect of old codebases are usually bigger than initially assumed. Programmers don't keep up with new technology and their career slowly but steadily grinds to a halt. – Peter Aug 25 '14 at 11:07
2

With these little facts you provided, it is impossible to tell.

In the end, this is a cost/benefit analysis.

  • What will the rewrite cost?
  • What cost does administration of the system create right now and what will it cost after the rewrite?
  • What's the current cost of doing a typical change to the system and what will be the cost after the rewrite?

Also keep in mind that even when you get some short-term personnel increase during the rewrite (like by hiring an external consulting firm to do it), the rewrite will cost you resources. That means the support situation will be worse while you do the rewrite. Also, forget about the wishful thinking that the new application will be perfect from day one. It will have bugs and design errors at first which will likely take several years to fix. It will take a while until it is just as productive as the old one.

When you keep all this in mind and quantify it in money, you should be able to create a cost/benefit analysis which says how long it will take until the investment has amortized itself. Provide this to management and have them decide if it is worth it or not.

You should also consider an alternative approach: Make the best out of what you have. You said "no one really knows what is going on inside the asp classic code". This sounds like a lack of documentation. Starting a project now to write a proper documentation for the system might help you in the future to make changes and do troubleshooting. While you do this you might also be able to identify the core problems with the system and find a fix for them without having to rewrite the code which works properly.

  • Also you need to be sure that what you're rewriting is actually broken and where to say with certainty that a rewrite will fix it. That may mean stepping on other people's toes which is never good for your career prospects. Equally that code could be a pet project of someone very high up. – James Snell Aug 25 '14 at 11:12
3

Some expert opinions on rewriting software. I especially like R.C. Martins "Big Redesign in the Sky".

Imho, even crappy software can improve over time. It will take time, it will be much effort, and it will certainly only work out if all team members want it to, because it requires that no new ugly code is written and that every component that is touched gets incrementally improved.

You might also wanna have a look at the Mikado-Method for Refactoring of large Legacy Software. It helps me a lot to remember that principle.

Hope this helps somewhat!

2

You don't want to do a rewrite, as you point out there are problems with that.

What you should do is refactor as you are working on it -- whenever you do something with one of the ASP classic pages, turn it into .Net. Basically you do the cleanup as you are working an issue. This of course adds additional work to individual tasks, but it isn't a complete "change it all now" and when doing the update, do as little as possible to get it to be .Net, don't rewrite the whole page if you don't have to.

Eventually you will have everything as .Net and then you can start on whatever the next cleanup task is.

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