Refactor vs. Rewrite • Hacker News Board

Re: Refactor vs. Rewrite

#71

Post by cientifico » Wed, Jun 03, 2020, 8:38 AM UTC

dagss wrote: post #67

cientifico wrote: post #64

In my experience, refactor vs rewrite is the wrong approach. Knowledge of the business must be maintained. If knowledge is on the team because the company is stable, rewrite. 37 signals is a clear example of this. If the knowledge is in the code, because multiple people or teams worked on the code base over the past few years, refactor. A rewrite will be the recipe for disaster. I never found an exception to this rul…

I have been responsible for an exception to this rule. We were new people coming in to take over, decided to go for rewrite, and were successful. But part of the reason for the rewrite was that the logic (translation of business domain knowledge into code) in the old version was wrong resulting in unstable behavior. It could have been fixed in the old version (very many places) but the lack of a test suite too tipped…

If you are able to get the domain knowledge fast enough, sure.

Or as you said, the domain knowledge has changed from the original.

Re: Refactor vs. Rewrite

#72

Post by eddieoz » Wed, Jun 03, 2020, 8:40 AM UTC

Probably it should consider the alignment to the business strategy. Developers tend to rewrite because of tech challenges. But I agree with the conclusion and rewrite should be considered if it is impacting the strategy.

Re: Refactor vs. Rewrite

#73

Post by rakoo » Wed, Jun 03, 2020, 8:43 AM UTC

dagss wrote: post #67

cientifico wrote: post #64

In my experience, refactor vs rewrite is the wrong approach. Knowledge of the business must be maintained. If knowledge is on the team because the company is stable, rewrite. 37 signals is a clear example of this. If the knowledge is in the code, because multiple people or teams worked on the code base over the past few years, refactor. A rewrite will be the recipe for disaster. I never found an exception to this rul…

I have been responsible for an exception to this rule. We were new people coming in to take over, decided to go for rewrite, and were successful. But part of the reason for the rewrite was that the logic (translation of business domain knowledge into code) in the old version was wrong resulting in unstable behavior. It could have been fixed in the old version (very many places) but the lack of a test suite too tipped…

It seems to me it's still not contradictory to GP: domain knowledge wasn't in the code, it was outside. The thing didn't work in all cases so you had to get the specs from something other than the code; rewriting according to this exterior source was the sensible thing to do

Re: Refactor vs. Rewrite

#74

Post by battery423 » Wed, Jun 03, 2020, 8:44 AM UTC

I would argue that rewrite is slightly more difficult then refactor. Refactor means, after all, making the current system better while rewrite would mean no update/change/feature on the current system and more pressure to get it done.

I would herby say that a good team with experienced people will succeed in both cases while an less experienced team will probably have a higher chance of doing a refactoring then a rewrite.

I like refactorings better. It allows me to optimize a system slow and steady.

I like rewriting better if you don't need to support the old env while doing the rewrite and having expierence in the old system.

Re: Refactor vs. Rewrite

#75

Post by fabian2k » Wed, Jun 03, 2020, 8:48 AM UTC

I found the move away from GraphQL again interesting, maybe because it supports some of my concerns about it. I never looked in detail into GraphQL, but just from the general principles I understand I found it rather scary to decide to use it.

It's a big complicated thing directly between the data and the frontend. If anything goes wrong there, now I have to debug a much more complex piece of software than if I use a REST API. And just like in the article, based on my superficial knowledge I was concerned that it could be easy to create bad queries, and hard to fix performance issues.

I'm not saying GraphQL is bad, I really don't know enough about it. But given the central position it takes, I would not feel comfortable deciding to use it without a serious amount of prototyping and getting to understand how it works. It often feels weird to me that such a complex piece in this kind of critical position is often casually recommended for any kind of web application.

Re: Refactor vs. Rewrite

#76

Post by dirtylowprofile » Wed, Jun 03, 2020, 9:03 AM UTC

My last 3 clients wanted me to rewrite their React Native apps back to native iOS and Android like in a separate codebase. I’m not sure if this is a trend but their common complaint was that they are sick of the performance of the app and each platfrom has a unique bug. Also this one project written in RN took like a year to develop.

Re: Refactor vs. Rewrite

#77

Post by yxhuvud » Wed, Jun 03, 2020, 9:08 AM UTC

3pt14159 wrote: post #4

I rewrote a codebase for a major stock exchange in about four months. It was originally in Ruby, which is my most proficient language, and my implementation was in Python, my second most proficient language. The original Ruby codebase had been worked on for years and was a complete mess. Not because of Ruby, but because the people that developed it were a little sloppy or junior or time pressured. Who knows? It's tot…

> Make sure you do a feature freeze before you start

Easier said than done. Oh, it is easy to get the deciding people to do lip service to it when planning the rewrite originally, but a lot harder to enforce it a few months down the line.

Re: Refactor vs. Rewrite

#78

Post by nottsdev » Wed, Jun 03, 2020, 9:38 AM UTC

gonzus wrote: post #53

nottsdev wrote: post #51

I think rewriting is a great option, provided both options are weighed up appropriately. However saying this, we made the decision to rewrite a legacy system around a year ago and the project got parked due to "urgent" projects being fed to our team. This was frustrating but we could not account for this external factor when weighing up the options.

I think changing priorities is a risk that has to be taken into account whenever you are considering any task that will extend for a long time -- rewriting code is just one example. If you have to go on for many weeks / months on a project without the possibility of showing intermediate results, it is naive not to think that there is a high risk of the project being cancelled.

I completely agree with you, it is just a complicated metric to factor in.

I guess one of the frustrations was the fact that our team had been been assigned with assurance that we will not be affected by changing priorities.

Re: Refactor vs. Rewrite

#79

Post by blackpanda » Wed, Jun 03, 2020, 9:58 AM UTC

I think we need to focus on even more basic point while deciding between refactor vs. rewrite. That is whether the basic DB schemas/Data Structures are well designed/suited to current business understanding or not. Because rest of the structure stands on top of them.

I do not see how you can refactor stuff if the majority of the DB schema/Data Structures are built incorrectly and/or not suited to current understanding/layout of the business. You will have to rewrite.

The only case where refactor can possibly work is that basic DB schema/Data Structures is 90% good and changes are only required at the business logic level.

Re: Refactor vs. Rewrite

#80

Post by yxhuvud » Wed, Jun 03, 2020, 10:00 AM UTC

zo1 wrote: post #60

Ericson2314 wrote: post #42

I think everyone is missing the big point here: they current implementation was in an untyped language and so refactoring was just to hard. Use languages with good type systems and then refactoring is easy, and always the correct technical choice. Let me say that again, the killer app of type systems is that no mistake can "total" the code.

The lack of static typing does not make refactoring incredibly hard or difficult. In fact, I would argue it's even easier due to the way dynamically-typed languages pass around data. Really, as long as you follow some basic rules and don't propagate complexity into your system too-much, refactoring is a breeze. When I do it, the types are inconsequential almost. The things I do worry about when refactoring is develop…

"This random corner case in this function returns a null, but I don't see the consumer handling nulls."

Modern type systems tend to incorporate handling of null values in the type system though.

I can recommend looking at Crystal. You will find that the overhead of providing sufficient types is pretty small.