|
Re: How to retain perl in-house code
by CountZero (Bishop) on Mar 27, 2008 at 21:03 UTC
|
Do they have any in-house Perl programmers? If not and they have programmers more conversant in the other language, I'm afraid your quest is doomed from the start.Missing documentation can hardly be blamed on Perl. One can write missing documentation in any language. Alas, the "complicated code" thing is something which will haunt Perl forever it seems. Telling them that it could have been written in a more understandable way is not going to help you. Could you not offer them to re-write these scripts into more "Perl Best Practices" compliant Perl? And add some tests too, so they have a fine base to upgrade their scripts if necessary? If they have to pay another programmer to re-write these scripts in another language, it will cost them a fair sum too and you already have obtained a good working knowledge of these scripts by documenting them. It seems to me you can thus undercut any other programmer who has to start froms scratch, unless you are very expensive of course! ;-) I had a similar issue last year in my company when the head of IT found out all my scripts are written in Perl (of which he understands nothing it seems) and wanted it to be re-done in another language (he was thinking of PHP, but only a small part of my scripts are web-server based). I then told him that he was going to exchange a perfectly working mission critical system for something which did not yet exist, which had to respond to a constantly changing environment at the drop of a hat and his already overworked IT department would never be able to do so in any reasonable period of time. He finally agreed with only the web-based parts to be switched to PHP as indeed Perl was far superior in the other tasks. The lesson from this story: argue from Perl's strengths (text processing & parsing) and don't pick a fight you cannot win.
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James
| [reply] |
Re: How to retain perl in-house code
by jhourcle (Prior) on Mar 27, 2008 at 20:56 UTC
|
They might have legitimate reasons for changing (the normal one being that they have a programmer on staff who knows some other language, and they don't have the time to maintain additional code ... of course, if that were the case, they wouldn't have time to re-write additional code, either).
Other legitimate reasons include wanting something compiled so that people can't as easily inspect the code, if it's something to be sold as a product, or to reduce complexity if the program has to interface with some other system that only provides language-specific APIs. There may also be issues with needing to reduce the execution time, memory footprint, or some other metric and they want to go to a compiled language for that.
...
Anyway, my typical issue is that if the code currently works correctly, there is the possibility of it not working correctly after the change. If they don't need to rewrite the script, it may be enough to have to documented to the state where someone else with only basic understanding of Perl can take over.
This is an initial savings to the company, as they don't invest more time to get to the same level of quality that they currently have. It can also reduce risk, as an incorrectly translated program may have defects in it ... depending on the project, that may not be acceptable (but if that was the case, they'd likely have better documentation).
One of the problems that I've run into, even staying within the same language, is that often the complexity is there for a reason -- handling edge cases, etc, and an attempt to rewrite the code might remove all of the embedded knowledge that the code contains.
| [reply] |
Re: How to retain perl in-house code
by eyepopslikeamosquito (Archbishop) on Mar 27, 2008 at 21:09 UTC
|
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.
| [reply] |
|
|
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] |
Re: How to retain perl in-house code
by Zen (Deacon) on Mar 27, 2008 at 20:49 UTC
|
Take one of those scripts, do the transformation documentation, then challenge another writer to write in whatever language they like. Compare it with a sane perl version. If it still loses, then it is deserved. | [reply] |
Re: How to retain perl in-house code
by nefigah (Monk) on Mar 27, 2008 at 22:02 UTC
|
Making them aware of how easy Perl::Tidy and Perl::Critic are to use could help--they can transform ugliness into prettiness pretty quick, and that would eliminate one of your problems. Then it's just a matter of going through and writing documentation, which is guaranteed to take less time than writing new code and documentation.
I'm a peripheral visionary... I can see into the future, but just way off to the side.
| [reply] |
Re: How to retain perl in-house code
by runrig (Abbot) on Mar 27, 2008 at 21:39 UTC
|
From your description, documenting the scripts doesn't sound like a bad thing, and if you document them well enough (and if they really are complicated enough), they may decide that rewriting them isn't worth it. If they do rewrite them, then it'll provide someone(s) plenty of work. | [reply] |
Re: How to retain perl in-house code
by sundialsvc4 (Abbot) on Mar 27, 2008 at 21:25 UTC
|
In a situation where you have the potential “to be, or not to be” an agent-of-change, the operative question is: is this a change that they want, or only one that you want?
I think it's the latter ... in which case you're wasting your energy. Do what they ask, and observe. Keep your opinions to yourself, at least for now.
| |
|
|
I disagree that, as a consultant, one's role is to simply shut up and do as you're told. I take the view that I am being hired for my expertise and to just keep my opinions to myself rather than freely offering that expertise would be a disservice.
When my clients request that I do something I disagree with (or something I simply don't want to do), I lay out my reasons, ask about why they want to do what they asked in the way they specified, and try to explain why my way would be the better option. It's also important to make it very clear to them that you'll gladly do it their way if that's still what they want after reviewing your arguments1, of course. My clients respect this and I have the distinct impression that it is one of the major reasons why my repeat customers keep coming back.
1 Provided that's true. One case that comes to mind is someone who wanted an application created which not only violated a third-party website's ToS, but also had a large degree of complexity specced which was clearly intended solely to bypass that site's attempts to enforce their ToS. When they displayed a lack of interest in looking for ways to obtain their data in a ToS-compliant manner, I said "I'm not comfortable with doing this project" and walked away.
| [reply] |
Re: How to retain perl in-house code
by pc88mxer (Vicar) on Mar 27, 2008 at 21:13 UTC
|
Do you know what the other language is? Any idea on what their dissatisfaction with perl is (what they want to do that they can't)?
| [reply] |
Re: How to retain perl in-house code
by arc_of_descent (Hermit) on Mar 28, 2008 at 19:18 UTC
|
If they are moving away from Perl thinking its an outdated language, this link might help you out.
Perl Myths
| [reply] |