4 ms·

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

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 totally possible to do a rewrite and to do it well. The advantage of having a pre-existing implementation is that it's far, far easier to write tests before you implement because most edge-cases are covered in the existing implementation. Make sure you do a feature freeze before you start, then once you're ready for production do both shadow testing and canary testing and things will go well.

majormajor 6y ago
> The advantage of having a pre-existing implementation is that it's far, far easier to write tests before you implement because most edge-cases are covered in the existing implementation. Make sure you do a feature freeze before you start, then once you're ready for production do both shadow testing and canary testing and things will go well. There are two ways I've seen it go vastly over schedule when these things bite you. 1) There might be edge cases covered in the original implementation that neither you nor current stakeholders remember or know about. So discovery can either take way longer than expected (until you're confident you know 100% of what the code does) or implementation can get constantly delayed by "oh, yeah, we do still need that." 2) Feature freezes are a rare gift. Usually it's "we need this new thing" which leads to engineering saying "that would be hard to do in the current system, we should rewrite it" so now you have to rebuild all the old stuff plus build the new thing. And its requirements will probably keep changing on you.
deleted 6y ago
[deleted]
celim307 6y ago
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
- Jtsummers 6y ago
  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).
  - 3pt14159 6y ago
    I'm the person that you're replying to responded to. This is exactly what I went through during that four month period. The existing tests weren't very useful and I was completely changing the structure of how the program was architected, but the input v output could be measured. I, like you, also discovered critical bugs in the existing implementation because I needed to cover the entire combinatorial set or possible inputs whilst the original implementers presumably went through them as they came up.
kelnos 6y ago
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.
Ididntdothis 6y ago
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.
yxhuvud 6y ago
> Make sure you do a feature freeze before you start Easier said than done. Oh, it is easy to get the deciding people to do lip service to it when planning the rewrite originally, but a lot harder to enforce it a few months down the line.

majormajor 6y ago

> The advantage of having a pre-existing implementation is that it's far, far easier to write tests before you implement because most edge-cases are covered in the existing implementation. Make sure you do a feature freeze before you start, then once you're ready for production do both shadow testing and canary testing and things will go well. There are two ways I've seen it go vastly over schedule when these things bite you. 1) There might be edge cases covered in the original implementation that neither you nor current stakeholders remember or know about. So discovery can either take way longer than expected (until you're confident you know 100% of what the code does) or implementation can get constantly delayed by "oh, yeah, we do still need that." 2) Feature freezes are a rare gift. Usually it's "we need this new thing" which leads to engineering saying "that would be hard to do in the current system, we should rewrite it" so now you have to rebuild all the old stuff plus build the new thing. And its requirements will probably keep changing on you.

deleted 6y ago

[deleted]

celim307 6y ago

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

Jtsummers 6y ago
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).
- 3pt14159 6y ago
  I'm the person that you're replying to responded to. This is exactly what I went through during that four month period. The existing tests weren't very useful and I was completely changing the structure of how the program was architected, but the input v output could be measured. I, like you, also discovered critical bugs in the existing implementation because I needed to cover the entire combinatorial set or possible inputs whilst the original implementers presumably went through them as they came up.

kelnos 6y ago

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.

Ididntdothis 6y ago

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.

yxhuvud 6y ago

> Make sure you do a feature freeze before you start Easier said than done. Oh, it is easy to get the deciding people to do lip service to it when planning the rewrite originally, but a lot harder to enforce it a few months down the line.