Complete rewrite - when justified and when not

Last post 01:31 pm September 5, 2014
by Charles Bradley
8 replies
Author
Messages
09:56 am August 29, 2014

Hi all,

When would you consider rewriting an app from scratch?

Background: Old (15+ years) large legacy app built using old technology and poor development practices (low code coverage, few unit tests, business logic mixed with ui etc.) majority of features are not used. Cost of change is constantly increasing. Market is pretty stable.

With rewriting I am not thinking that the new system would contain all the features of the original app but that you would start over from a clean slate and build something small, get feedback, iterate. What factors are important to take into consideration? I'd appreciate if anyone has any stories to share of successful/unsuccessful attempts.

There are plenty of articles out there that strongly argue against this
http://www.joelonsoftware.com/articles/fog0000000069.html
http://onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-R…
http://steveblank.com/2011/01/25/startup-suicide-%E2%80%93-rewriting-th…

01:24 pm August 29, 2014

I especially like and agree with that 2nd article.

I don't think I could describe a scenario where I would re-write an app from scratch, as there is way too much context involved in that, and I'm not sure I'd ever find a scenario where I'd agree with it.

I much prefer the strangler pattern instead: http://martinfowler.com/bliki/StranglerApplication.html

I would also be sure to put my technical folks and line mgmt through some serious tech training before I started down that road, to make sure the same mistakes are not repeated over again! Scrum.org's PSD course is a good start.

01:26 pm August 29, 2014

I should also mention that I'd put mgmt and executives through some EBM training before going down that road, because it would appear that they are not paying attention to the metrics that they should be.

More here: http://EBMgt.org

01:35 pm August 29, 2014

> Market is pretty stable.

Perhaps that is another way of saying it hasn't been disrupted yet

> With rewriting I am not thinking that the new system would contain all
> the features of the original app but that you would start over from a
> clean slate and build something small, get feedback, iterate.

That's the correct mindset to have. You need to identify the new MVP by formulating and then testing various hypotheses. That could involve mock-ups or even questionnaires just to test a market reaction. You already seem familiar with some of Steve Blank's work, and an Enterprise Lean Startup approach seems wise in your situation.

10:12 am September 4, 2014

Charles,

Thanks for your comments - insightful as always.
I would say development practices has been much improved since the app was originally developed. I don't think that you can ever avoid "mistakes", you will hopefully not repeat old mistakes but you are destined to make new ones...

What specific metrics are you referring to? I am familiar with the strangler pattern, but in this case I'd be afraid that getting rid of the rarely used features might take more effort than creating new features in a new system. Purging these from the existing code base would give no business value.

12:17 pm September 4, 2014

Metrics, the ones listed on this page: http://ebmgt.org/Solutions/Agility-Index-Snapshot

The business value of removing features that are not valuable or not used are:
* less clutter in your app
* lower maintenance costs/TCO
* your team learns to pay more attention to feature usage/customer satisfaction

12:20 pm September 4, 2014

> I would say development practices has been much improved since the app was originally developed.

A lot of people say that. In all of my experiences when people say that, I've never been convinced that it's true. People often "don't know what they don't know"

04:47 am September 5, 2014

Thanks Charles,

I hear what you're saying but software is re-written all the time and I have a had time thinking they are all failures. What circumstances made you go/not go down that path?

01:31 pm September 5, 2014

In my 13yrs as a Java Consultant, I got the chance to see dozens of teams and their technical practices. With very few exceptions, the vast majority of people and software teams completely over-estimate their technical practices and skills. In addition, very very few people ever take the time to improve their skills at companies, because the incentives are misaligned to schedule/scope/cost. I think much of this is caused by Taylorism management paradigms, but some of it is just the natural tendency to over estimate one's skills, and the fact that most humans don't account for "unknown unknowns".

[I should also mention that I've been a part of and have witnessed several re-writes in my career]

More practically speaking, the need for a *total* re-write is a long term culmination of technical debt, poor technical practices, and/or getting out of touch with your customer. The vast majority of those deficiencies will still exist in those who've been around the company and were largely responsible for getting the system in the ditch in the first place.

Incremental re-writes via the strangler pattern mitigate the risk of making all of those mistakes over and over and over again. They're also much less risky to the business, and can help nudge you to re-connect with your customers.