|
Stegalex has asked for the wisdom of the Perl Monks concerning the following question:
Fellow monks,
I have been successfully running Perl websites since 1999 and am completely happy with it. Unfortunately, some butt-munch manager in our IT department has decided to make an issue of my website being crafted from "Antiquated Technology". Given the fact that his idea of "state of the art" is Cold Fusion, can you please help me come up with some *objective* bullet points in defense of continuing to use Perl?
My architecture is as follows:
- RH Linux (not at issue here)
- Apache2
- mod_perl2
- Embperl::Object (I know, it's crusty but solid)
- DBI
- Oracle 10G (not at issue here)
Thank you. |
Re: In Defense of Perl
by Old_Gray_Bear (Bishop) on Jan 12, 2010 at 15:59 UTC
|
Tactfully remind the boss of the "butt-munch manager in our IT department" about the First Law of Systems Analysis:
"A new system has to work at least as well as the system it replaces".
Go along with the B-BM's plans to 'update' the web-site infrastructure; make sure that your User Base is aware that "Changes Are Being Made"; make sure that The Users know that you are their friend and contact point when the Changes go Sour; Help the B-MM implement his Grand (and flawed) Vision. In short look at this as an Opportunity. Here is your chance to learn 'new' technology (learning is always good), become a Hero to the Users (for looking out for their interests during this time of turmoil), and be in position when the Drech starts drifting toward the fan to reduce the User Impact.
Seriously, there are a few questions that need to be addressed by the User Community and the B-MM's upper managers:
- Are the Users happy with what they have?
- How much is it going to cost to re-implement just that functionality?
- Are there projects that can better serve the Company? Investing time and money to re-invent an already functioning wheel is not a Bright Idea, with respect to the Corporate bottom line.
- Are there new functions that the Users need/want?
- Can they be easily done in the New Technology and integrated with what already have in place? If not, then the cost of Re-Inventing the Wheel becomes part of the BM-M's problem. Have fun selling that to the Accountants -- cost of adding the New User Widget in the New Technology: $x; cost of re-writing our entire web-site so that the New Widget will integrate: $XXXX....
- Can you easily implement the New Functionality in Perl? (" Dear BM-M things are pretty quiet this week. Oh, I got bored last Saturday afternoon and I wrote a Perl implementation of of the New Widget. I've shown it to a couple of the Uber-Users, and they loved it and suggested a couple of tweaks, which I put together for them over lunch yesterday. The U-U are now asking about the roll-out plans for the New Widget. I told them that you'd have to make that call. By the way, I have some ideas for the New New-Widget that I'd like to float by everyone. Are you free for a meeting with the U-U tomorrow morning at 0900 to discuss the schedule? Love, OGB")
- Reguardless of what happens, get your resume refreshed. A BM-M who wants to have change for the sake of increasing his budget is likely to go hunting for scape-goats then things fail.
Update -- added missing close-tag.
----
I Go Back to Sleep, Now.
OGB
| [reply] |
Re: In Defense of Perl
by steve (Deacon) on Jan 12, 2010 at 17:19 UTC
|
Features and facts about Perl that may help your discussion:
- Perl 5.10 was released December 18, 2007 - perhaps not as antiquated as it is made out to be
- Perl is included by default in both Linux and MacOSX distributions which implies both stability and widespread use
- Perl ports are available for many other operating systems
- 18,000 modules available on CPAN (and many of them are very well written, tested, and maintained)
- Ability to include and use C/C++ code and XS modules
- Free for business/enterprise use (compare ColdFusion Pricing)
- More than 20 years of development
- Great defect density (see report)
- Passes the homeland security test (see results)
- ModPerl allows for Apache integration
- Apparently you already have a Perl codebase
Perhaps you could also benefit from a discussion with the manager in question and identify his/her concerns and needs. In the end he/she may just not like Perl, and there may be nothing that you can do to change that (in which case you can either learn ColdFusion or find another source of employment). If this manager has real concerns that can be addressed you may be able to explain how Perl can resolve these concerns. | [reply] |
|
|
| [reply] |
Re: In Defense of Perl
by almut (Canon) on Jan 12, 2010 at 15:46 UTC
|
- Why recreate something from scratch that works and looks fine?
Present an estimate of the time and money it would take to rebuild the site with Cold Fusion and ask whether they're willing to spend it.
| [reply] |
Re: In Defense of Perl
by eyepopslikeamosquito (Archbishop) on Jan 13, 2010 at 01:21 UTC
|
You might point your manager at On Not Rewriting by Joel Spolsky.
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?
If your manager spends a lot of money rewriting your working code
in Cold Fusion, adds no new features, and (as is likely)
introduces new bugs in the process, he will start to smell very badly.
See also:
| [reply] |
Re: In Defense of Perl
by Jenda (Abbot) on Jan 12, 2010 at 16:46 UTC
|
| [reply] |
Re: In Defense of Perl
by shawnhcorey (Friar) on Jan 12, 2010 at 20:52 UTC
|
If he believes Cold Fusion is state of the art, then any technical reasons you give him will be ignored. He has decided that he is the Manager, God's Gift to the company. Instead, concentrate on how much it would cost to convert. Get some real numbers. And don't fight him alone. Look for other projects that can "benefit" from converting to Cold Fusion and talk to their managers. Ask them if they're willing to share those costs that can be distributed. Make sure everyone knows how much a disruption this Cunning Plan of his will cost, both in money and time.
| [reply] |
Re: In Defense of Perl
by scorpio17 (Canon) on Jan 12, 2010 at 17:55 UTC
|
A big plus in favor of perl is CPAN. It's been said (reference needed) that over 90% of any project you'll ever need to build has already been written by someone else, and it's just sitting on CPAN waiting to be downloaded.
A big negative for ColdFusion is that it's a commercially owned product, marketed by Adobe - not open source, like perl. This means they can force you to upgrade to a "new & improved" version that's totally incompatible with everything you've previously developed (they probably won't, but still, it's a risk worth considering).
| [reply] |
Re: In Defense of Perl
by Burak (Chaplain) on Jan 12, 2010 at 15:32 UTC
|
If he/she thinks your setup is antiquated, you can show off with a sample application using Catalyst + Template Toolkit and some ORM magic with Rose::DB & friends. Then instead of using that state of the art sucky template language, you can still use Perl. If he/she wants a new application you can point to a new direction :) | [reply] |
Re: In Defense of Perl
by davies (Prior) on Jan 13, 2010 at 00:45 UTC
|
Two questions my father always used to ask (as a pair).
What is the upside potential?
What is the downside risk?
Quantify that downside risk. How much would you lose if the new system failed to various degrees? Estimate percentages for the various degrees (and I would estimate utter failure at 5% to 10% at least. If you have any records of failed projects, you might be able to calculate something precise). Multiply the percentages by the losses. Add them up. This is the "expected value" (shown as a negative) of failure.
The next negative number is the "opportunity cost". The staff who are rewriting a working system could be doing something more profitable. Estimate the amount of time it will take to write the new system. Estimate the cost of the staff - and multiply it by four. Explain that a multiplier of between three and five is necessary to cover holidays, training, sickness, management, unproductive time, overheads like rent and computers and, of course, profit. I wish I had some authority to quote you on this, but I assure you it's accurate. If the auditors are around, they will probably know their own chargeout rates. Ask them what the rate is divided by the pay per hour. Explain what you are doing and that you are only looking for an approximation.
To be fair, it is essential that you put in the savings that the new system will make - the upside potential. These are the costs of failure you used earlier, but the percentages will be lower because the chance of total failure of a working system is known to be zero (but put in something like 1% anyway). Don't gild the lily - you don't need to. This is the "expected value" of the new system - a positive number.
Add the three numbers up - two negative and a positive. This is the loss (negative) that can reasonably be expected from taking a decision to rewrite the system. Of course, if the number comes out positive, you should rewrite. But based on what you have said, it won't. Prepare a presentation and show it to a beancounter. Use the terms I have put in quotes - they are standard accounting terminology that will be understood. Then let the beancounter kill the project for you.
Sorry about the absence of bullet points, and good luck!
John Davies B.Acc, CA(SA), ACMA but no programming qualifications whatsoever | [reply] |
Re: In Defense of Perl
by Stegalex (Chaplain) on Jan 12, 2010 at 15:24 UTC
|
One more thing, visually, the site is very modern. It's full of Web 2.0 content. It's not being characterized as "antiquated" because of the way it looks or works. I have a very, very happy user base. | [reply] |
Re: In Defense of Perl
by lyklev (Pilgrim) on Jan 12, 2010 at 22:31 UTC
|
I guess your manager got a free lunch somewhere...
Seriously, his concern is probably long-term support. He might believe that finding relatively cheap Java trainees programmers is easier than finding cheap Perl programmers.
| [reply] |
Re: In Defense of Perl
by JavaFan (Canon) on Jan 12, 2010 at 15:40 UTC
|
can you please help me come up with some *objective* bullet points in defense of continuing to use Perl?
- You go to perlmonks for objective bullet points? Right...
- If you cannot come with reasons to use Perl, I think you've already lost your case. It's your manager, your department, your website. Explain to him why you used Perl. After all, your reason are likely to be different from mine.
- I mostly use subjective reasons to determine which tool to use for which task. Primary reason to pick X over Y is, "I know X, I don't know Y". I don't think there's a more subjective reason. Neither do I think it's wrong to have subjective reasons.
- At least I got you bulletpoints.
| [reply] |
|
|
Don't make me engage in a flame war with you, JavaFan.
Yes, I come to Perlmonks for objective bullet points because it's worked in the past for me (although you always have to filter out people who insist on monologuing). I *can* come up with points of my own, it's just that I like to cast a wider net and get the opinions of others (probably not a skill you are familiar with). Subjective reasons aren't something I bring to management.
One of the things I would like to do is to point out large, commercial websites that are still running Perl. I know that Amazon.com used to run Perl, but I doubt that is the case today.
Which big sites run Perl?
Thanks.
| [reply] |
|
|
Which big sites run Perl?
(Updated: added BBC)
Perl 6 - links to (nearly) everything that is Perl 6.
| [reply] |
|
|
|
|
|
|
Ticketmaster too. Amazon still uses Perl extensively; in the early days it was C and Perl and in house stuff, then a *lot* of Java came and a little Ruby in and some Perl went out, and then Perl staged a bit of a come back.
| [reply] |
Re: In Defense of Perl
by 5mi11er (Deacon) on Feb 10, 2010 at 15:53 UTC
|
Unfortunately, what you have is a religious war on your hands. Many have given excellent business advice on ways to combat it above, but there are also many historical and current computer related religious wars from which you may be able to glean insight from. There's a nice list to be found here.
Any time people argue about any topic, and those people's beliefs are rooted in fundamentally different places, the argument can not be resolved until they are able to find common ground from which to work. Those giving business arguments are hoping that your manager will be swayed by business logic to abandon his attacks. If he stands to lose 'face' by continuing to attack, it is likely that will work, but it isn't guaranteed. In the end, as evidenced by the prevalence of these 'wars' and the length of time many have been perpetuated, it is often an ugly and protracted battle. Study up on "The Art of War", arm your self well, and my you win the good fight.
-Scott | [reply] |
|
|
