Live data from Hacker News

Refactor vs. Rewrite

remesh.blog

11–20 of 123 posts

Re: Refactor vs. Rewrite

#11
post #9

This blog post doesn't seem to mention how long the process took - that's what I'm most interested in!

Yes, this is the key warning of Spolsky’s post [1]: The rewrite team had invested years of work and still had nothing shippable.

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Re: Refactor vs. Rewrite

#12

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.

Re: Refactor vs. Rewrite

#13
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…

God bless whoever wrote tests before you. Whether it be a rewrite or working on the current code base, those who have the time and resources and don't write tests are inexcusable and bad stewards

Re: Refactor vs. Rewrite

#14
post #12

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.

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

Re: Refactor vs. Rewrite

#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 sluggishness was unfortunately coming from AngularJS. We tried some performance improvements, but it wasn't getting very far.

We built some prototypes using other Javascript frameworks, and found VueJS gave us the best performance.

Management was concerned about us rewriting. The end customer was concerned about us rewriting. So risky! But we saw no other way to deliver adequate software performance.

We got done on time, with great system performance, to the accolades of a very happy end customer.

Re: Refactor vs. Rewrite

#16
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…

I'm not sure it's super common that many companies would agree to a 4-month feature freeze.

I don't think having a existing implementation makes it easier to write tests. I think having a ton of domain knowledge about the system and what inputs it could possibly get is what helps you here. And all the better if the existing impl also has a comprehensive test suite that can be feasibly 'ported' to the new language.

The existing implementation helps you if you decide to come up with new tests, because you can compare the result of those tests with the old and new implementations. But if you don't even know what new tests to write (which requires domain knowledge), you're stuck.

Re: Refactor vs. Rewrite

#17
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.

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.

Re: Refactor vs. Rewrite

#18

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.

> In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

Re: Refactor vs. Rewrite

#20
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…

God bless whoever wrote tests before you. Whether it be a rewrite or working on the current code base, those who have the time and resources and don't write tests are inexcusable and bad stewards

Sometimes you can produce tests (not unit, but integration and such) from the existing system by treating it as an oracle. That's what I did once, it worked really well and in the end of the differences between it and mine (where mine technically failed the tests), we found out the old system had dozens of critical bugs and mine hand a handful (old system gave many false negatives, which was a major no-no, mine gave some false positives which were tolerable; manual inspection can clear up the latter but not the former).
Post reply on HN