Re: How to retain perl in-house code

From a business point of view, rewriting working code (without changing its function) doesn't make sense: you are spending lots of time and money without improving the user experience. Indeed, the user experience may get a lot worse if you introduce new bugs in the rewrite. After all, the user doesn't usually care what language a product is written in. Would this time and money be better spent in adding new customer-requested features? You might point them at On Not Rewriting by Joel Spolsky.

Comment on Re: How to retain perl in-house code

Replies are listed 'Best First'.
Re^2: How to retain perl in-house code by amarquis (Curate) on Mar 27, 2008 at 22:30 UTC
This is what I came into this thread to say. Rewriting from scratch: Burns time you aren't sure to ever recoup with whatever perceived time-saving benefits there will be in the new version. Is time spent spinning your wheels, feature-wise. Customers walk away from stagnant product. Sacrifices a known system with known bugs for an unknown system with unknown bugs. I'm not sure if not having Perl expertise on hand is a worthy argument either. Experience tells me that good programmers can work with anything that was written with a little care and was well documented. And if it is important enough that the slowness of the non-Perl programmer doing maintenance would be a waste, it seems likely it would be important enough to think about a new hire.	[reply]

Replies are listed 'Best First'.

Re^2: How to retain perl in-house code
by amarquis (Curate) on Mar 27, 2008 at 22:30 UTC

This is what I came into this thread to say. Rewriting from scratch:

Burns time you aren't sure to ever recoup with whatever perceived time-saving benefits there will be in the new version.
Is time spent spinning your wheels, feature-wise. Customers walk away from stagnant product.
Sacrifices a known system with known bugs for an unknown system with unknown bugs.

I'm not sure if not having Perl expertise on hand is a worthy argument either. Experience tells me that good programmers can work with anything that was written with a little care and was well documented. And if it is important enough that the slowness of the non-Perl programmer doing maintenance would be a waste, it seems likely it would be important enough to think about a new hire.

[reply]