Everyone has done "successful" rewrites. But a rewrite that takes 2 years and requires a team much larger than the original team isn't successful in the eyes of most stakeholders and is almost NEVER what the dev team proposes as the timeline. Just because something got done eventually at great cost doesn't make it successful.

Quoting parent: "plus internationalisation, plus thorough automated tests and deployment. They seemed to be really happy with it."

Sounds like success.

There is a reason why stakeholder would like the change despite large cost - if the old system was unstable and source of stress and fires for the stakeholders, they will go for more expensive option.

Kind of like after you had a car that needed to be fixed every few weeks, you will go for more expensive higher quality one next time.

That's why a good strategy is to never put yourself in the position to communicate a timeline. If you are knowledgeable enough about a project so you can make an informed decision that a rewrite is required, the strangler pattern can allow you to complete such a project without ever formally requesting a "rewrite".

If the executives don't get a timeline from you, they'll get it from someone less knowledgeable. Estimates made in ignorance are almost always underestimates because they omit critical work the estimator is unaware of. Therefore, this (bad) estimate will also be a "lowball" estimate, but it will be the only hard number executives have to make their decision. So they'll greenlight the rewrite and more than likely put the lowball estimator in charge. Being vocal, honest, and credible about estimates and the true cost of projects is always the best move.

The strategy is to be vocal, honest and credible by estimating features, not the whole rewrite. The rewrite happens by strangling the original application, feature by feature.

Our team is doing a slow replacement of code written in Java to node. At almost every turn we find that the replaced code is 50 to 80 percent smaller and much easier to read. We're doing it slow because we are phasing in new features at the same time to make sure stakeholders get value while we do it. It's been tremendously successful and cost effective keeping the old and the new running simultaneously.

Awesome results! Is the new code smaller due to the different programming language (JS) or a better understanding of the program's requirements?

Sadly just converting poorly written code that doesn't use re-use mostly. Other than that, we're using multiple typescript frameworks for data wrangling and transport and validation without having to re-define objects as DTOs, Models, etc... And taking advantage of graphql has been, massively helpful.

A bit off-topic but: what made you go to Javascript specifically?

> Just because something got done eventually at a great cost doesn't make it successful

Are you arguing that success is in the eye of the stakeholder? Sounded to me like it was a success.

>> Just because something got done eventually at a great cost doesn't make it successful

> Are you arguing that success is in the eye of the stakeholder? Sounded to me like it was a success.

I think a lot of these stories make sense if you replace software re-write with a home construction project gone overbudget, one where the overage comes out of your pocket.

I'd say that something that gets done eventually at a great cost is not successful if the case made for doing the project was an overly rosy story of how easy/inexpensive it would be to do. It really hurts when you pay for it, and that is the perspective to take.

As for success being in the eye of the stakeholder, sort of -- in my analogy, the construction company might consider it a success all the way to the bank. That project owner may consider it a success to save face. The project sponsor would likely not.

Then I think the good criteria to apply here is: what was the goal of the project?

If it was a quick cash-grab then obviously a long and expensive rewrite is deemed unsuccessful. If you go for the long haul and want to bring real value to your customers and the rewrite helped you do that, then it was a success.

Nothing is ever cheap in IT in my opinion. I found that being very upfront with the people with the money landed me more projects than trying to lie about it and reveal the extra expenses one by one over a course of a year.

"No, that's gonna be very far from 50k euros. Be prepared to pay 300k and it's not gonna be a year. Optimisically, two, realistically, two and half to three."

It works surprisingly well with experienced businessmen. They applaud the honesty and we move directly to the next point -- what are the tradeoffs and compromises.

I've done a rewrite of a major website with another HN'er in about a month of close collaboration. Nobody even realized the platform had been changed before we told them. The original team was a large number of people working part time over a large number of years. Enough cruft had accumulated that a rewrite was the only way to deal with it.

Thanks to Charles Pick (phpnode on here) and pretty tight plan we got the job done in record time. Yes, we could have done even better. But we did not have the budget and the time so we worked within those constraints and got the job done. Would have been super to work with more people, more budget and several months to do it. But as it was it was already a huge improvement over what was there before.

It's exactly what we proposed, and the stakeholders loved it. This is just more ghost story.

At work we're in the position where three of our main competitors are struggling bad after all trying to rewrite their software. Good for us, we've captured a number of their clients due to this.

We've instead focused replacing parts of the program over time. If we touch some old code that works but needs to be extended for a new feature, we usually rewrite it and bring it up to date as part of implementing that feature. Other times it might be too sensitive and we just modify a small piece of the old code and let it chug along like it has done for over 15 years.

Instead of spending time rewriting the whole shebang we can deliver features, alternatively not having a second team reimplementing everything avoids a huge financial burden.

I should add that you cannot forget the sales side when deciding on doing a rewrite. That is, how are you going to recover the cost of the rewrite?

One of our struggling competitors has, as far as I know, a decent replacement in the form of a rewritten product. But trying to recover the cost they're trying to pitch it as an upgrade. So a license to the new version is much more expensive.

Apparently a lot of clients either do not see the added value over their current version, or, given the higher price, they're considering alternatives such as us.

Doesn't that count as a (successful) rewrite strategy as well?

Perhaps. For me saying "we're gonna rewrite this program" means a specific effort over a relatively short timescale. Incremental or not (when switching platform for example).

With our approach we will likely have some code that's 10-15 years old now and which still be untouched for another 5-10 years.

I argue that’s not a rewrite because it’s not a fundamental architecture change that requires a huge shift and lift (with the accompanying monolithic deployment critical section and associated risks). It’s just an application of the strangler pattern to do incremental component changes.

This is the way I prefer to do rewrites too. In the end you usually end up with most code rewritten, without it taking too much time. Then the last bit to get it all rewritten isn't so hard.

>> So i just want to tell you that i've done successful rewrites! [...] It took a couple of years, the rewrite team was 2-5 times the size of the team that built the old site

So what makes this rewrite successfull? I am sure in that time you could have easily added the I18N, tests and deployment and refactored the most difficult parts of the code so that it would be more expandable and easier to maintain.

> So what makes this rewrite successfull?

That it was successfully completed and the tech provides a better basis for future features? Sometimes timeframe and team size are almost irrelevant to the success of a rewrite project.

I cannot possibly imagine how timeframe and team size are considered irrelevant to success.

Business needs still matter. Time and money is still a thing.

Not saying that time and money is unimportant, but sometimes time and money are the soft(er) constraints. Extreme example: the toolchain is lost and the original application can not be built anymore, but the business currently swims in money.

I am definitely not saying that adding that good stuff to the existing app incrementally was impossible. They could have done that. But for "strategic" reasons, the stakeholders wanted to replatform, and we did that.

This. I was part of a team that did a rewrite of a product at a large well-known company. Also, saw rewrites happen throughout my career that I wasn't directly a part of but were happening in the same company I happened to be working at.

Maybe I've been lucky but they were all raging successes. At the end everyone is relieved and happy and much back slapping ensues.

I like Spolsky's articles but I hate the dogmatic culture a writer like him creates. His article on rewrites is always a thing whenever I've been part of a discussion on rewrites. It's an anecdote, nothing more.

> I like Spolsky's articles but I hate the dogmatic culture a writer like him creates.

But without creating that dogmatic culture, would his writing have become popular enough to be disseminated to a wide audience?

Perhaps we should think of it as a corollary to the Gell-Mann amnesia effect.[1]

1: https://en.wikipedia.org/wiki/Gell-Mann_amnesia_effect

> without creating that dogmatic culture, would his writing have become popular enough to be disseminated to a wide audience

Personally, I think you have the cause and effect switched around. Would his opinions be considered dogmatic if he weren't so popular?

The 'Spolsky article' may be opinionated and simplistic, but the article on which it was based makes some salient points that should be weighed carefully.

People usually tend to accept that efforts to build a products are oftentimes underestimated, but somehow accepting the same kind of underestimation is hard. So what? Even if the rewrite takes more time and money it can still be successful if it substantially reduces costs, relative to the original software. The important part is to push through the hard part to receive adoption.