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

31–40 of 123 posts

Re: Refactor vs. Rewrite

#31

Post by KKKKkkkk1 »

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 because it's calm and gentle. It's a paradise if you're a visual person. There are no formal design reviews, so there are no huge decision points. Instead, we can make the decisions fluid. Since we iterate every day and never have dumb-ass presentations, we don't run into major disagreements.

Re: Refactor vs. Rewrite

#32

Post by xwdv »

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.

Certainly possible to make a good one on the first try. A great one? Probably not, unless you are doing something absolutely trivial and done several times before, like a CRUD app.

Re: Refactor vs. Rewrite

#33

Post by WalterBright »

mattkerle wrote: post #30
WalterBright wrote: post #25

I constantly refactor my code, even the ancient stuff. Here's my most recent one: https://github.com/dlang/dmd/pull/11202 which changes a data structure from a linked list to an array.

I was about to comment something sarcastic, then I googled you and instead I'll just say thanks!

I don't mind if you say something sarcastic, but I am happy to say "you're welcome!"

Re: Refactor vs. Rewrite

#34

Post by satyrnein »

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.

Re: Refactor vs. Rewrite

#35

Post by Ididntdothis »

jeffbee wrote: post #17
sdenton4 wrote: post #14

Earlier quoted context omitted.

No good plan survives first contact with the enemy... Less pithily, the good architecture will almost certainly end up with arbitrary patches and madness after 2 years of active use, if anyone cares about it at all... And then somebody will join and say 'This is a mess, we should refactor and/or burn it to the ground.'

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.

To some degree that's matter of luck. Sometimes all your assumptions are correct from the start and the requirements don't change much. But often a lot of things change over time until the first architecture doesn't fit anymore. I would agree there are better and worse architects but luck definitely plays a role.

Re: Refactor vs. Rewrite

#36

Post by Ididntdothis »

WalterBright wrote: post #22
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 have yet to know any such people :-)

Just avoid touching anything complex :-)

Re: Refactor vs. Rewrite

#37

Post by Ididntdothis »

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…

If you could do it in 4 months i seems to be a relatively simple system. It's also not clear how your new code will adapt to changes in the next few years. It may end up in a big mess again.

Re: Refactor vs. Rewrite

#38

Post by bdcravens »

I feel there's room for something in-between (reimplementation? resurrection?): start with a clean slate, and bringing in large swaths of functionality and code and then rebuilding other parts. I think this is useful when you have a lot of work to upgrade an older version of your core framework or many dependencies, you're changing a large piece of your infrastructure (like a database), or you have a lot of work to "fix" your test suite.

Re: Refactor vs. Rewrite

#39

Post by BurningFrog »

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.

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.

Re: Refactor vs. Rewrite

#40

Post by cryptonector »

Some rewrites can be easy because a better technology exists that makes it easy. For example, you might have a NoSQL DB with lots of hand-rolled queries, and then you get a query language for it, so now you can rewrite a great deal of code. You still hand-roll transactions because eventual consistency, CAP, and all that, but then you get a SQL DB that... gives you all of that anyways but with good ole SQL (with eventual consistency, not ACID, but hey, CAP), so now you can rewrite the queries and the transactions, and maybe that's the lion's share of the app, so you've essentially rewritten the app. What about the REST layer? Well, you get inspired by PostgREST and write a similar tool for your new DB and there's nothing left of the original.
Post reply on HN