4

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?

Improve this question
4
  • 2
    possible duplicate of How can I sell a legacy program rewrite to the business?
    – gbjbaanb
    Commented Jun 28, 2012 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".
    – vaughandroid
    Commented Jun 28, 2012 at 10:44
  • Ah, I see @Andrew Finnell has said something along similar lines. Listen to him. ;)
    – vaughandroid
    Commented Jun 28, 2012 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.
    – snakehiss
    Commented Dec 27, 2012 at 8:58

4 Answers 4

Reset to default
14

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

Improve this answer
1
  • 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
    Commented Jun 1, 2013 at 17:48
8

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.

Improve this answer
1
  • 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
    Commented Jun 29, 2012 at 4:30
5

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.

Improve this answer
0
0

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

Improve this answer
2
  • 1
    That lower left quadrant should also have the "ignore" or "sunset" options since it's of low business value.
    – Jesse C. Slicer
    Commented Dec 26, 2012 at 22:13
  • @JesseC.Slicer You are right. Although you can rewrite it ti add business value.
    – Tulains Córdova
    Commented Dec 26, 2012 at 22:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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