Refactor vs. Rewrite • Hacker News Board

Re: Refactor vs. Rewrite

#41

Post by recursive » Wed, Jun 03, 2020, 5:22 AM UTC

jjeaff wrote: post #29

MaulingMonkey wrote: post #21

Earlier quoted context omitted.

> There are lots of systems that are more or less right in version 1. While true, in my experience this usually happened when at least one - if not all three - of these conditions were true: 1. The problem domain is relatively static, unmoving, and self contained 2. The systems in question is relatively small 3. The developers in question have written substantially similar systems before, or ground locally, or used v…

4. A system that never needs to scale much beyond its original projected load.

First read as "original project lead", but I think that could apply too.

Re: Refactor vs. Rewrite

#42

Post by Ericson2314 » Wed, Jun 03, 2020, 5:34 AM UTC

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.

Re: Refactor vs. Rewrite

#43

Post by Chris_Newton » Wed, Jun 03, 2020, 5:53 AM UTC

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.

Rewriting implies rewriting legacy code (regressions) and wasting time.

This isn’t necessarily true. A few years ago, we rewrote a large part of a web-based UI. The original implementation was a Java applet, a reasonable choice for an interactive diagram at the time it was first written. However, over time the applet had become a liability because browsers were planning to drop support, and in the meantime some useful alternative technologies had become available. In a situation where you are porting an established system to run on a new platform, rewriting really is the only way and therefore isn’t a waste of time.

Re: Refactor vs. Rewrite

#44

Post by [deleted] » Wed, Jun 03, 2020, 6:08 AM UTC

jeffbee wrote: post #12

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…

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.

[deleted]

Re: Refactor vs. Rewrite

#45

Post by bsaul » Wed, Jun 03, 2020, 6:19 AM UTC

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.

yeap, this is a good point. This is the first time i see a rewrite to "older". Older architecture, older language, older methodology. And the only part that serm to not have met expectation are the ones using new stuffs ( graphql and maybe typescript).

Maybe there's a rule here : complete rewrite is ok if you're rewriting to "older" tech.

Re: Refactor vs. Rewrite

#46

Post by ratww » Wed, Jun 03, 2020, 6:28 AM UTC

recursive wrote: post #41

jjeaff wrote: post #29

Earlier quoted context omitted.

4. A system that never needs to scale much beyond its original projected load.

First read as "original project lead", but I think that could apply too.

That's certainly true in my experience. I've seen some great, readable, codebases written by solo developers that had lots of previous experience writing code in larger teams.

Caveat: it's never something that's too large or complex, of course.

Re: Refactor vs. Rewrite

#47

Post by moksly » Wed, Jun 03, 2020, 6:46 AM UTC

Ididntdothis wrote: post #36

WalterBright wrote: post #22

Earlier quoted context omitted.

I have yet to know any such people :-)

Just avoid touching anything complex :-)

Or a deadline.

Re: Refactor vs. Rewrite

#48

Post by momokoko » Wed, Jun 03, 2020, 6:58 AM UTC

tjr wrote: post #15

My team inherited a 70%-complete AngularJS application, the user interface for a passengers and crew on a new series of airplanes. It worked fine enough on modern tablets and phones, but there were also some interface devices hardwired into the planes, which would be very challenging to update at this point, and on those devices the software ran very slow. Through several experiments, we determined that the sluggishn…

I’m my career, UI rewrites have been By far the most successful.

It may just be anecdotal, but my assumption has been that most of the edge cases are more easily identified because UIs are by nature going to have most of their business logic visible to the human eye.

Re: Refactor vs. Rewrite

#49

Post by toast0 » Wed, Jun 03, 2020, 6:59 AM UTC

MaulingMonkey wrote: post #21

jeffbee wrote: post #17

Earlier quoted context omitted.

I don't doubt that this could accurately reflect your experience in the industry, but it is not a universal truth. I've worked on sustaining engineering of systems that were years old, the stewardship of which involved refactoring only, and which are still in production today. There are lots of systems that are more or less right in version 1.

> There are lots of systems that are more or less right in version 1. While true, in my experience this usually happened when at least one - if not all three - of these conditions were true: 1. The problem domain is relatively static, unmoving, and self contained 2. The systems in question is relatively small 3. The developers in question have written substantially similar systems before, or ground locally, or used v…

0. The requirements were known in advance of starting the design.

Re: Refactor vs. Rewrite

#50

Post by nikofeyn » Wed, Jun 03, 2020, 7:07 AM UTC

KKKKkkkk1 wrote: post #31

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…

Here's a nice quote from Jony Ive to support your point Much of the design process is a conversation, a back-and-forth as we walk around the tables and play with the models. [Steve Jobs] doesn't like to read complex drawings. He wants to see and feel a model. He's right. I get surprised when we make a model and then realize it's rubbish, even though based on CAD renderings it looked great. He loves coming in here bec…

i'm not sure ive has a lot of lessons to give on evolving an architecture in a way that improves maintainability and adds functionality. ive's entire MO revolved around removing those two things from the systems he designed.