4 ms·

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 re

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.

a8da6b0c91d 12y ago
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?
- Demiurge 12y ago
  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.
- antonpirker 12y ago
  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.
troels 12y ago
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.

a8da6b0c91d 12y ago

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?

Demiurge 12y ago
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.
antonpirker 12y ago
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.

troels 12y ago

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.