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

101–110 of 123 posts

Re: Refactor vs. Rewrite

#101

Post by jspash »

devonkim wrote: post #98
satyrnein wrote: post #34

So they got off of Elixir and microservices, but their introduction of Typescript and GraphQL didn't pay off like they hoped, and now they need to get off GraphQL. I think the lesson of "Choose boring technology" applies here. One of the reasons rewrites are risky is that very often the new tech doesn't live up to expectations.

If the business model is boring, you’ll need complex technology to compensate. If your business model is complex like in a lot of enterprise software, you should strive to keep the technology as simple as possible. Simple doesn’t mean to not use complex or cutting edge things IMO but to be conservative in using things that push the cognitive load of your collective team. A 10 person company probably doesn’t need a K8…

"If the business model is boring, you’ll need complex technology to compensate." Could you elaborate on this? What is the complexity compensating for? Boredom of the developers?

Re: Refactor vs. Rewrite

#102

Post by WJW »

satyrnein wrote: post #91
albertzeyer wrote: post #63

I think Google even has a policy that almost all parts of code in their mono-repo needs to be rewritten (not just refactored) every 2 years or sth like that.

I guess nobody felt like rewriting Google Reader!

Not "significantly technically challenging" enough, so no promotion opportunities there.

Re: Refactor vs. Rewrite

#103

Post by commandlinefan »

bearjaws wrote: post #95
aazaa wrote: post #93

> ... We had very poor test coverage in the areas most in need of refactoring because they were the oldest code, written before we established good test practices. That's probably not a coincidence. I like to ask those most strongly opposed to test-first development how they refactor code. I have yet to get an answer the leads to anything other than a rewrite at some point. Of course, the rewrite might be coming for…

How is this a test-first argument? You can write tests at anytime, bad discipline is bad discipline. I've never worked somewhere that didn't write tests because "they didn't write them first", they didn't write them because they were an immature organization. My current job leaves it up to the developers, and most don't write tests first. Its no miracle that despite us not writing tests first, all changes have their…

> You can write tests at anytime

Actually, every single Java enterprise application I've worked on for the past 20 years has been test-resistant: the developers declare everything "public static" so none of the application can be run without running all of the rest of it (since each class imports another that transitively imports everything else, all with static initializers that read configuration files and connect to live database instances). Every refactor/rewrite I've ever suggested has been specifically to allow tests to be written.

Re: Refactor vs. Rewrite

#104

Post by commandlinefan »

sys_64738 wrote: post #5

When a developer says "I am going to rewrite ..." you have to question why? If you were not doing this "rewrite" then what else would you be doing? Refactor is usually a term used to minimally modify legacy code to allow new functionality to be added. Rewriting implies rewriting legacy code (regressions) and wasting time. If a developer says "it's the only way" then you need to be sure you can trust their judgement.

I often suggest rewriting (or large-scale refactoring) to modularize big balls of mud to permit automated testing. I can always justify this by pointing out how much time is wasted doing manual testing, as well as how much time is wasted starting up a full-blown instance of an app and then navigating to where the problem is just to troubleshoot something.

In my experience, though, "rewriting is wasting time" types reject that reasoning because they don't really have a good handle of software engineering concepts.

Re: Refactor vs. Rewrite

#105

Post by commandlinefan »

dep_b wrote: post #90

I hear more often things like "oh I don't have experience with X, so let's not use it". I mean programming languages are easy, frameworks are hard. Like learning how to use Django (which is pretty easy as far as frameworks go) to me seems harder than using React (assuming I know that already) with TypeScript instead of JavaScript. I would probably be really happy to use TypeScript instead. If Elixir was a really bad…

> programming languages are easy, frameworks are hard

That's been my observation as well, but I find myself surrounded by folks who insist that any framework should be a ten-minute tutorial away from mastery (even people who ought to know better).

Re: Refactor vs. Rewrite

#106

Post by wiennat »

satyrnein wrote: post #34

So they got off of Elixir and microservices, but their introduction of Typescript and GraphQL didn't pay off like they hoped, and now they need to get off GraphQL. I think the lesson of "Choose boring technology" applies here. One of the reasons rewrites are risky is that very often the new tech doesn't live up to expectations.

I am also in the middle of moving off graphql to REST api. It is a 5 years old project and the graphql part was implemented with a very old spec. Since it has not been well maintained, it could not catch up with any features offered by graphql and users need to write their own queries by hand due to spec compatibility.

Rewriting it to REST allows us to "rebrand" these apis. At least, it does not scare our api users as the word "graphql" did.

Re: Refactor vs. Rewrite

#107

Post by Ericson2314 »

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.

No, it's really easy: change a definition's type, and then fix each type error. The errors give you a guided tour of the codebase that's impossible to get without static type checking.

Re: Refactor vs. Rewrite

#108

Post by BurningFrog »

collyw wrote: post #62
BurningFrog wrote: post #39

Earlier quoted context omitted.

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.

I'm always building something I've never built before. And the requirements always change as you go.

So knowing what I'm building in advance never really happens.

Re: Refactor vs. Rewrite

#109

Post by ansgri »

jspash wrote: post #101
devonkim wrote: post #98

Earlier quoted context omitted.

If the business model is boring, you’ll need complex technology to compensate. If your business model is complex like in a lot of enterprise software, you should strive to keep the technology as simple as possible. Simple doesn’t mean to not use complex or cutting edge things IMO but to be conservative in using things that push the cognitive load of your collective team. A 10 person company probably doesn’t need a K8…

"If the business model is boring, you’ll need complex technology to compensate." Could you elaborate on this? What is the complexity compensating for? Boredom of the developers?

I suppose the boring business model needs some secret sauce, i.e. advanced technology, to stay competitive -- since it's boring, many people are likely to do it, the margins are thin, you need to optimize.

Re: Refactor vs. Rewrite

#110

Post by constantine42 »

megameter wrote: post #2

IME whether you rewrite or refactor, the lesson is the same: You have to grind your way into the good architecture. It doesn't become good because the code is fresh, but because you have battle scars to show. And a success story in that case comes from having a complete learning loop. In a lot of orgs the learning itself is argued against for one reason or another - development proceeds with as little feedback on qua…

"Grind" your way into good architecture? Good architecture is designing, not trial-and-errored. The only grinding I do is mental before I type a single letter of code.
Post reply on HN