Hacker News Reader

Comment by troels | Hacker News Reader

My experience from doing rewrites is that if at all possible (and it usually is, even if you don't think so), do the rewrite incrementally. For example, in the case described here, they wanted to switch rdbms, change up the schema, change the application level implementation/framework and change the interface all at once. That's a lot of risk to combine.

Maybe they could have started by refactoring the schema in-place (That is, within mysql and webtek). Then change from mysql to pgsql - still behind webtek. Maybe separating the change of webtek -> django from the interface change is a bit harder, but you could still try to restrain your self as much as possible and then make a second iteration of the interface after the initial change.

I've taken this approach before, when migrating a big product and it worked quite well. It seems as a lot of extra work at first, but I'm pretty sure that is not actually case.

View on HN

Doing it incrementally is definitely the best. However, in your scenario, the problem of a 'weird' codebase people have a hard time using is not addressed by requiring further development in it. Database layout is usually not the problem if the system was at all functional.

Having done this a few times, when switching from old to new, the new framework would have a DB agnostic ORM. What works nicely is building the models, duplicate templating, getting a mirror working. Shut down the old site, and then it's possible to go on with normal development.

So, it is important to consider rewrite and redesign as separate goals.

The thing is though - if no one understands the existing system, how could you ever hope to build a new one that provides the same functionality? You'll have to interrogate that system to find out how it functions in order to replicate it. I find that this is often easier done by incremental refactorings of the legacy codebase (And writing a test harness in the process). So the rewrite really becomes a mission of analysing/documentation.

However messy it may be, there's usually a lot of domain knowledge to be learned from such a legacy codebase.

In this case porting from perl to python makes it much harder and seems pointless. Why not just keep it in perl but incrementally move to a modern perl framework?

Why do we see so many more posts about Django compared to 'modern Perl framework'? Python has killer features like simple syntax and developer familiarity. Django has GeoDjango.

This isn't even a question to me, but to the blog author. My. Point is about order of steps in the rewrite. It is not harder to rewrite first, redesign second, it is easier. I've done it multiple times in c++/c#, perl/python, php/python, r/python.

One consideration to switch from Perl to Python was that it is easier to find Python/Django developers because more young developers learn Python than Perl. Perl developers (at least in Austria) are mostly seniors and thus most of them already have a good job. (And do not want to change jobs) And a mature Perl developer is more expensive than a young Python developer.

Working incrementally definitely makes sense. Also if you don't see a chance to do it in an incremental way you should probably take a step back and ask yourself if the old application is maybe too huge and monolithic and check if there's a possibility to make it more modular. So you could split one huge application in smaller parts/services which can easier evolve seperately from the rest.

Very much agree. Slicing the existing application up in smaller parts and migrating those piecemeal is another form of incremental rewriting, as opposed to working through one layer at a time.

It's sometimes a judgement call, though. If an incremental approach is too expensive, haphazard, or just not technically sound, doing a soft launch and gradually transitioning users can work well too. This obviously has it's own drawbacks and complexities but it's a good alternative if an in-place upgrade isn't feasible. That said, at the end of the day an all-or-nothing release really should be the last resort.

Reply on news.ycombinator.com