Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Refactor vs. Rewrite

remesh.blog

Post reply on HN
Print view View original

61–70 of 123 posts

Re: Refactor vs. Rewrite

#61

Post by jillesvangurp »

Chris_Newton wrote: post #56
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.

More expressive type systems might make refactoring safer , but they don’t necessarily make it easier . The former happens because it’s harder to change something encoded in the types accidentally. For the latter, it should be easier to change something encoded in the types deliberately, but often the opposite is true.

Having a type system enables zero risk automated refactorings, even complex ones and make them a no brainer. Not having that builds a reluctance to do even simple refactorings.

A good example is the simplest possible refactoring: renaming things. I was doing this in pycharm on a simple python project the other day and it proposed modifying just about all dependencies on the classpath because it couldn't tell apart things that were in scope and out of scope of the refactoring. I've seen similar things happen on javascript and ruby codebases. Renaming things is a PITA in those languages. Not safe at all.

On any Kotlin or Java code base I do this all the time without thinking twice. I rename stuff, I move stuff, extract variables, auto fix things, etc. It just happens. A rename is a complete non issue for that. Doesn't matter if it's a local variable or the package name of your entire code base. You can trivially modify thousands of lines of code with a keystroke without breaking stuff.

Re: Refactor vs. Rewrite

#62

Post by collyw »

BurningFrog wrote: post #39
jeffbee wrote: post #12

Earlier quoted context omitted.

I feel like you have denied the existence of people who are capable of writing down a good architecture on the first try, without all the grinding.

I'd suspect anyone who claims that is a bit full of himself. Maybe their work isn't so great to other people. Or maybe it is. I won't rule it out. But I also think that anyone who does this probably works too hard. It's so much easier to build things incrementally.

>It's so much easier to build things incrementally.

I would say its much easier if you know what you are building in advance. Building incrementally is usually more about exploring ambiguous ideas and not having a clear vision in my experience.

Re: Refactor vs. Rewrite

#64

Post by cientifico »

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 rule.

Re: Refactor vs. Rewrite

#65

Post by jillesvangurp »

It's always a judgment call. But in general, there are a few things that make the choice easy.

Any UI project, I tend to look at the expected shelf life of the thing knowing full well that most UI projects get discarded pretty quickly. Stuff like backbone, angular 1, etc. were pretty popular a few years ago and you don't hear a lot about people whining about refactoring those. Mostly those code bases have already been changed; several times probably or abandoned.

So, if we have a bit of UI and it's important for it to be right and it is clearly not and I have a team of developers leaning towards unceremoniously dumping the old code base, I'm not going to object very long or hard. The reality is that it probably can be fixed but all the people interested in doing that have gone.

For backend systems it's different. I regularly see code bases with long histories. Often a good sign of how good they are is if people can work on them with confidence. In those cases, I lean towards doing more incremental changes. Update dependencies, modernize a few things even if they've been fine, etc. If that's not the case, it's a net cost sink and something needs to be done.

Re: Refactor vs. Rewrite

#66

Post by franciscop »

> a handful of engineers focused on machine learning (ML). [...] We leaned into a singular moderator talking to a group of people.

I am curious about why an early chat/conference company needs so many ML Engineers? What are you using them for?

(the Remesh mentioned in the article seems to be https://remesh.chat/ and not https://remesh.ai/, based on previous articles, the logo and blog domain)

Re: Refactor vs. Rewrite

#67

Post by dagss »

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 the scales for rewrite (with test suite).

You can say that we learned the domain (at least) as well as the authors of original system after coming in, but won't that be the case of any successful rewrite?..

Re: Refactor vs. Rewrite

#68

Post by Cthulhu_ »

I'm in the middle of a rewrite, but because my employer also wants me to do work on the existing application, I end up doing a lot of refactoring as well - if only for my own sanity and to help me understand the existing code.

We're talking an only 8 year old (continuously developed during that time) app built in PHP and JS, but by someone who never bothered to learn web development proper. Resulting in a lot of copy / pasted code, string concatenation to produce HTML, etc. The problem isn't so much that, it's that the original developer was also highly productive, so the codebase exploded to nearly 200K LOC.

They recognized the existing UI was not going to work, so after the previous developer left, they put out a job advert to which I was recruited for. The job being to rewrite the application with modern technologies, with stuff like structure and tests built in this time.

I was okay with that, I mean I could probably do some things with the existing UI but it would be very labor intensive and if it was ever finished, it would still be a mid-2000's-looking Dojo app.

I've (for now) decided on Go and React, deploying it as a self-contained application (our distribution is via RPM packages on bare metal or virtual servers). Not sure about Go at the moment, most work is straight data manipulation (think REST API, database and writing XML files), struggling a bit with things like data consistency (because Go won't enforce you to set all fields, mind you neither does Java but you can have Lombok generate constructors and the like).

Anyway, my problem right now is that I was hired under the premise that maintenance of the old app would be like a day a week at most. Of course, in practice they're asking me to add new features to the existing application, so I've been spending over half my time on it instead, not making much headway with the rebuild.

My fear right now is that they'll scrap the new UI in favor of just keeping the old one around. But there was an article a while ago that pointed things like that out, I believe it was titled something like "why rewrites fail". Very close to home.

I mean I still believe a rewrite will be beneficial, but it's going to take at least another year and a half I think before it's feasible to replace the existing UI.

Should have a chat with the boss whether we can hire more people to work on it and / or the existing application.

Re: Refactor vs. Rewrite

#69

Post by barking »

I don't know if this is off-topic or not. More times than I care to admit I've lost hours of coding due to crashing without saving first. Without exception when I redo the lost code it's far better designed than the original and usually (not always) in a lot less time. I'd almost be inclined to recommend always throwing away your first completed effort and rewriting it while your mind's fresh.

Re: Refactor vs. Rewrite

#70

Post by gampleman »

A really undervalues idea in software development is architecting software for rewriting it in the future. If you make your software small and well defined, then it becomes a reasonable investment to simply rewrite it from scratch.

This is a great talk about this idea: https://vimeo.com/108441214

Post reply on HN