This blog post doesn't seem to mention how long the process took - that's what I'm most interested in!
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
11–20 of 123 posts
This blog post doesn't seem to mention how long the process took - that's what I'm most interested in!
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
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 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…
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.
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.'
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.
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 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.
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.'
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.
Strangle that monolith and none will be the wiser.
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