4 ms·

It's coincidental that this should be on the front page of HN the night before my team and I release a big migration that has taken the best part of a year. Th

It's coincidental that this should be on the front page of HN the night before my team and I release a big migration that has taken the best part of a year. The codebase he describes is an eerily accurate representation of where we started, with the added complication that it was built by a sole developer than wasn't using any version control at all. There are roughly 600k lines of Perl code in the back-end alone, but because there was a lot of duplication in lieu of version control, I have no way of knowing how much of this was actually in use. I suspect roughly 100-150k. Our approach was pulling the platform apart into distinct (Ruby) services and putting HTTP interfaces around some of the legacy services where possible. We've ended up with < 15k of Ruby, including the front-ends. It's not perfect but there haven't been many major issues in our pilot release, and the team is happy. Fingers crossed.

jsnell 13y ago
The obvious question is: how large was your team? While a lot of the commenters here seem somehow outraged at the computations, 5.5 man years seemed like a very aggressive schedule for rewriting a 1MLOC system, even if the end result were a 100KLOC one. My initial guess would have been 10 man years, and a cost in the millions. So here you have what was probably a 150KLOC original system. How many man-years would you guess the rewrite took?
- anarchitect 13y ago
  Three, plus a part-time contractor. One of the team is front-end so had little to do with replacing the Perl part. The truth of it is, in our case it isn't (yet) a full rewrite, and there is still a lot of functionality tied up in the existing codebase. So it's not easy to answer the question about man years, but I would guess around 1.5. The biggest wins for us in terms of lines of code were not the language (we did consider sticking with Perl), but re-assessing the business logic, ridding the codebase of legacy junk and using existing libraries instead of hand-rolled solutions.
  - bluej4ack 13y ago
    The way you did it seems to be the most logical (and obvious) approach, which the article completely neglects to mention
joe_the_user 13y ago
Good for you, However, I would mention that this doesn't match the alleged situation in article, a million lines in heavy use. Your app sound like it's real complexity was considerably less. Given that at least complexity goes up with size of the code, your success still might not mean that diving into the situation described in the article would be a good idea.
- anarchitect 13y ago
  In all likelihood our scenario is less complex than in the one described in the article. That said, the code we are replacing is in constant use and powers all our online stores, the main source of revenue for our company.

jsnell 13y ago

The obvious question is: how large was your team? While a lot of the commenters here seem somehow outraged at the computations, 5.5 man years seemed like a very aggressive schedule for rewriting a 1MLOC system, even if the end result were a 100KLOC one. My initial guess would have been 10 man years, and a cost in the millions. So here you have what was probably a 150KLOC original system. How many man-years would you guess the rewrite took?

anarchitect 13y ago
Three, plus a part-time contractor. One of the team is front-end so had little to do with replacing the Perl part. The truth of it is, in our case it isn't (yet) a full rewrite, and there is still a lot of functionality tied up in the existing codebase. So it's not easy to answer the question about man years, but I would guess around 1.5. The biggest wins for us in terms of lines of code were not the language (we did consider sticking with Perl), but re-assessing the business logic, ridding the codebase of legacy junk and using existing libraries instead of hand-rolled solutions.
- bluej4ack 13y ago
  The way you did it seems to be the most logical (and obvious) approach, which the article completely neglects to mention

joe_the_user 13y ago

Good for you, However, I would mention that this doesn't match the alleged situation in article, a million lines in heavy use. Your app sound like it's real complexity was considerably less. Given that at least complexity goes up with size of the code, your success still might not mean that diving into the situation described in the article would be a good idea.

anarchitect 13y ago
In all likelihood our scenario is less complex than in the one described in the article. That said, the code we are replacing is in constant use and powers all our online stores, the main source of revenue for our company.