Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have been supporting a LOB winforms application for a client the last 3 years. The application is built with a simple monolithic architecture and uses .NET 2.0.

The application is a core part of their operations and its longevity is paramount. It needs to evolve with their evolving business processes, as well as implement improved functionality etc....this brings me to believe that this application needs an overhaul of sorts on the back-end.

The problem is changing a back-end is "invisible"...i.e. the user never actually sees it. It's a quality of the system that is changing (stability, maintainability, reliability, longevity), not some functional requirement that will be easily seen...i.e. the ROI is not obvious.

There is a lot of new functionality to be added to the front-end as well (user experience). I am considering a strategy of changing the back-end over time...i.e. when making a change or adding a feature to the front-end, change those components in the back-end that are affected, eventually you get to everything.

How do I convince the client that we need to rebuild the back-end?

share|improve this question
2  
possible duplicate of How can I sell a legacy program rewrite to the business? –  gbjbaanb Jun 28 '12 at 9:14
2  
For starters, stop calling it a "rewrite". That sounds like starting again from scratch, which is (commendably) not what you're talking about. Start calling it an "improvement", or "update", or even "evolution". –  Baqueta Jun 28 '12 at 10:44
    
Ah, I see @Andrew Finnell has said something along similar lines. Listen to him. ;) –  Baqueta Jun 28 '12 at 10:44
    
The justification of a rewrite is always the same. A cost benefit analysis which shows it's more expensive not to rewrite. I'm continually surprised how often people try to justify a rewrite by waiving hands and using phrases they learned on the internet; instead of some reasonable analysis and costing. –  dietbuddha Dec 27 '12 at 8:58
add comment

4 Answers

up vote 12 down vote accepted

If you discuss it the way the question is asked, you can't. What the client will hear is "bla bla bla, I want to play with a shiny new toy, bla bla bla, its going to cost you a heap of money, bla bla bla"

What you need to do it put in in context of whats important to them. "The backend is coming to the end of it's working life. If you want to continue to provide core services to your end users cost effectively, and have the ability to support the new features they will be expecting and take advantage of the faster and cheaper developmenent cycles provided by modern tools, you need to plan a migration path to a more modern platform that will scale well. I am more than happy to put together a proposal"

If you need to talk technology at this stage, you will (and should) loose. Plenty of mission critical systems were written 20 or 40 years ago, and despite the retoric, it's more cost effective to pay Cobol programmers than it is to rebuild it using [Insert latest buzz word/silver bullet here]

Read Things You Should Never Do, Part I

share|improve this answer
    
I worked at a firm 1 year ago and we had a couple of COBOL devs there. It was kind of weird, I felt like it was 1992. Didn't even know COBOL positions still existend or that someone still learns such an ancient language... –  Radu Murzea Jun 1 '13 at 17:48
add comment

when making a change or adding a feature to the front-end, change those components in the back-end that are affected, eventually you get to everything.

How do I convince the client that we need to rebuild the back-end?

These two statements seem at odds to me. A rewrite is very different then evolving an application such that it is different a year from now. A complete rewrite is almost a guaranteed failure.

You don't tell them you will be rewriting the back-end. You do exactly what you said before, fix the rotting code as you come to it. Eventually the back-end may evolve into something else but a complete rewrite means 1) Their "new" back-end won't be working for a long time 2) Their existing back-end won't be fixed for a long time. It's a lose-lose situation to do a complete rewrite.

share|improve this answer
    
Almost marked this as the answer but the other one had the link to Joel's blog post which I thought was awesome. Thanks for your answer! –  Richard DesLonde Jun 29 '12 at 4:30
add comment

By showing them how they will either save money or make more money by doing this rewrite, and since you say it's critical to their operation - that they will not be inconvenienced in any way while the rewrite is going on.

share|improve this answer
1  
+1 show them the money –  jk. Jun 28 '12 at 11:43
add comment

A rewrite is not the same as a reengineer.

I have posted this in other similar questions.

This chart could help sell the idea of a rewrite/replace/reengineer, it's a function of code base quality and business value of the application:

enter image description here

share|improve this answer
1  
That lower left quadrant should also have the "ignore" or "sunset" options since it's of low business value. –  Jesse C. Slicer Dec 26 '12 at 22:13
    
@JesseC.Slicer You are right. Although you can rewrite it ti add business value. –  user61852 Dec 26 '12 at 22:27
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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