Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > advocacy advice

Reply
Thread Tools

advocacy advice

 
 
Larry
Guest
Posts: n/a
 
      05-13-2005
I work in a Unix support organization for a Federal agency. Over the
past few months (with the aproval of my division's management) I have
rewritten some legacy shell scripts in Perl, which has given me the
opportunity to improve their functionality in many ways, as well as to
make the operation of the scripts more consistent with each other and
to "factor out" a lot of repeated code into a custom module.

Now, another division in my agency that is involved with the same
project has discovered this rewrite and raised a challenge to my
division's management and has even asked us to revert all the scripts
back to the old shell versions. I'm now being asked to prepare a case
before a review board to defend the use of Perl.

Does anyone have any advice for this situation or can you point me to
some resources for such a presentation?

Thanks!

 
Reply With Quote
 
 
 
 
Chris Mattern
Guest
Posts: n/a
 
      05-13-2005
Larry wrote:

> I work in a Unix support organization for a Federal agency. Over the
> past few months (with the aproval of my division's management) I have
> rewritten some legacy shell scripts in Perl, which has given me the
> opportunity to improve their functionality in many ways, as well as to
> make the operation of the scripts more consistent with each other and
> to "factor out" a lot of repeated code into a custom module.
>
> Now, another division in my agency that is involved with the same
> project has discovered this rewrite and raised a challenge to my
> division's management and has even asked us to revert all the scripts
> back to the old shell versions. I'm now being asked to prepare a case
> before a review board to defend the use of Perl.
>
> Does anyone have any advice for this situation or can you point me to
> some resources for such a presentation?
>
> Thanks!


What Unix are you running? It almost certainly came with Perl. Why
can't you use a language that came with the box?

--
Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"
 
Reply With Quote
 
 
 
 
Tad McClellan
Guest
Posts: n/a
 
      05-13-2005
Larry <(E-Mail Removed)> wrote:

> can you point me to
> some resources for such a presentation?



The Perl Advocacy mailing list:

http://lists.perl.org/showlist.cgi?name=advocacy


--
Tad McClellan SGML consulting
http://www.velocityreviews.com/forums/(E-Mail Removed) Perl programming
Fort Worth, Texas
 
Reply With Quote
 
Tad McClellan
Guest
Posts: n/a
 
      05-13-2005
Larry <(E-Mail Removed)> wrote:

> I work in a Unix support organization for a Federal agency.



The Federal Bankruptcy court has a large committment to using Perl.


--
Tad McClellan SGML consulting
(E-Mail Removed) Perl programming
Fort Worth, Texas
 
Reply With Quote
 
Eric Schwartz
Guest
Posts: n/a
 
      05-13-2005
"Larry" <(E-Mail Removed)> writes:
> Now, another division in my agency that is involved with the same
> project has discovered this rewrite and raised a challenge to my
> division's management and has even asked us to revert all the scripts
> back to the old shell versions. I'm now being asked to prepare a case
> before a review board to defend the use of Perl.
>
> Does anyone have any advice for this situation or can you point me to
> some resources for such a presentation?


The most important thing to consider is /why/ they want you to revert
back to the shell scripts. If you know that, then you know how to
prepare your response.


If they're worried that you have a very complex system, and that your
rewrites might change some subtle third-order effect that people have
been relying upon since 1983 to make sure nuclear missiles don't fall
on Dubuqe, then you want to be very careful in pointing out how your
code does precisely and exactly the same that the shell code did, and
is more readable and maintainable to boot!

If they are worried that you're the only Perl guy, and if you get hit
by a bus, they're screwed, try pointing out the vast number of Perl
consultants available to help them. Also, I don't know how your
agency is, but I know some people that have worked for DoD, and they
were required to take X hours of training every year-- you could
suggest a Perl class for people that might need to understand or
maintain your code.

Another thing to remember is that just because other people know Perl
doesn't mean they know it well enough to pick up after you if you get
hit by a bus. Probably one of the best things you can do to justify
your use of Perl is to point to a number of other people on your team
(or even the other division's team) that know Perl well enough to pick
up after you. Offer to host a brown-bag or more formal presentation
to familiarize anyone who wants to know with how your code works.

You will probably also want to present to them with the required level
of Perl knowledge someone would need to understand your code. I have
run into experienced (I do not say proficient) Perl coders who are
uncomfortable with the use of even basic constructs like map(); I'm
just the opposite, sometimes running to more succinct constructs that
could be expressed in a larger number of more easily understood lines
of code.

Remember, just by using Perl alone, you have set a standard of "you
must be this high to ride this ride"; the constructs you use, be it OO
programming, or even simply breaking code out into modules, raise the
bar incrementally higher. None of this is inherently bad, mind you,
but it is something people who aren't comfortable with Perl will want
to know. Do they need to hire Larry Wall, or will some snot-nosed
teenager with a copy of "Learn Perl in 21 Days" be able to figure out
what you're doing?

If you can, you might even walk them through a shell script mess and
then through the happy sunlit cheery Perl version of it, and contrast
how much simpler and more maintainable the Perl version is compared to
the horribly nasty ugly doom-laden shell script.

Above all else, remember: they're probably not inherently being
assholes. They're objecting to Perl for what they perceive to be
valid reasons. You need to find out what they are, and address them
head-on. Try to talk around it, or snow the review board with
whizziness, and you'll lose for sure.

-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.
 
Reply With Quote
 
Eric Schwartz
Guest
Posts: n/a
 
      05-13-2005
"Larry" <(E-Mail Removed)> writes:
> Now, another division in my agency that is involved with the same
> project has discovered this rewrite and raised a challenge to my
> division's management and has even asked us to revert all the scripts
> back to the old shell versions. I'm now being asked to prepare a case
> before a review board to defend the use of Perl.
>
> Does anyone have any advice for this situation or can you point me to
> some resources for such a presentation?


Another thing that just hit me was this snippet from

http://www.wall.org/~larry/natural.html

Multiple ways to say the same thing

This one is more of an anthropological feature. People not only
learn as they go, but come from different backgrounds, and will
learn a different subset of the language first. It's Officially
Okay in the Perl realm to program in the subset of Perl
corresponding to sed, or awk, or C, or shell, or BASIC, or Lisp,
or Python. Or FORTRAN, even. Just because Perl is the melting pot
of computer languages doesn't mean you have to stir.

This may help reassure them somewhat that esoteric Perl knowledge is
not required. Assuming, of course, that that is all or part of their
objection-- again, in any form of communication, be it art, writing,
or God forbid, PowerPoint, if you don't know your audience, you lose.

-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.
 
Reply With Quote
 
Peter Scott
Guest
Posts: n/a
 
      05-14-2005
On Fri, 13 May 2005 13:31:10 -0700, Larry wrote:

> I work in a Unix support organization for a Federal agency. Over the
> past few months (with the aproval of my division's management) I have
> rewritten some legacy shell scripts in Perl, which has given me the
> opportunity to improve their functionality in many ways, as well as to
> make the operation of the scripts more consistent with each other and
> to "factor out" a lot of repeated code into a custom module.
>
> Now, another division in my agency that is involved with the same
> project has discovered this rewrite and raised a challenge to my
> division's management and has even asked us to revert all the scripts
> back to the old shell versions. I'm now being asked to prepare a case
> before a review board to defend the use of Perl.
>
> Does anyone have any advice for this situation or can you point me to
> some resources for such a presentation?


I have experience in such environments and situations. It would help
if you posted the objections they are making. It would not surprise me
if they had not told you what their objections are, but finding out
would be extremely useful. Their objections may be oddball and easily
dismissed.

It is also likely that the true reason for the objection is political
(e.g., "We don't know Perl as well as you and so we will lose control and
hence turf") as opposed to technical. If the stated objection is
technical but technical refutations fail to persuade, that would be a big
clue. You can only win this situation by discovering the real objection.

If their concerns are technical, your best counterargument is likely to be
the reduced cost of maintenance due to using Perl. You should have been
able to shrink the line count to a small fraction of what it was.

--
Peter Scott
http://www.perlmedic.com/
http://www.perldebugged.com/

 
Reply With Quote
 
brian d foy
Guest
Posts: n/a
 
      05-14-2005
In article <(E-Mail Removed)>, Tad McClellan
<(E-Mail Removed)> wrote:

> Larry <(E-Mail Removed)> wrote:
>
> > I work in a Unix support organization for a Federal agency.

>
>
> The Federal Bankruptcy court has a large committment to using Perl.


I personally know the people slinging Perl for the US Treasury Dept.
and The US Census Bureau.

http://www.linuxdevcenter.com/pub/a/..._interview.htm
l

--
brian d foy, (E-Mail Removed)
Subscribe to The Perl Review: http://www.theperlreview.com
 
Reply With Quote
 
Larry
Guest
Posts: n/a
 
      05-16-2005
>From what I can gather, it is very close to the what you said... "We
don't know Perl as well as you and so we will lose control and hence
turf".

This other group I'm up against is considered a "development" group
(even though they mainly package and tweak COTS software). They
originally provided a set of shell scripts (ksh) about a year ago, when
they handed the project over to my group, which is considered a
"production support" group .

My group ran into problems and limitations of the shell scripts almost
from the beginning. It was obvious that they were hitting the limits
of the complexity that is appropriate for a shell script, and there
were lots of things that they were doing in an overly complicated way,
and not very well, just because it was a shell script.

(Example: to query info from a database and construct commands from it,
the shell scripts were calling a command-line database tool, stripping
out the formatting and messages to extract the data. Instead of using
string concatenation to form commands from the data, the shell scripts
were sticking constant strings into SQL with SQL concatenation
operators. The Perl version uses DBI to connect to the database and
the Perl "." operator to concatenate the data with constant strings to
form the commands).

We originally requested the development group to make the changes to
the shell scripts that we required, but they kept us waiting for 2
months because they didn't have the "resources" at the time to help us.
At that point, we gave up and started modifying the shell scripts on
our own (the other group never did get back to us) and we eventually
started converting them one by one to Perl. Once they were converted
they were a lot easier to modify and tweak the way we wanted them, and
they also worked better and more consistently.

Now suddenly the "development" team has some time on their hands and
has suddenly noticed that we've converted all "their" scripts and are
in a snit about it. I think the underlying problem is they think that
we've done work that really should have been their job, and if using
Perl was a good idea, they should have thought of it.

(As an aside, it seems that group has almost no familiarity with Perl,
because another thing they are doing is adapting their shell scripts to
a Windows project, using a shell script emulator.)

 
Reply With Quote
 
Larry
Guest
Posts: n/a
 
      05-16-2005
Just to clarify my last point ... that the other group has almost no
familiarity with Perl... one of their original objections to Perl was
that it won't run on Windows. As soon as I heard that, I got all of
our scripts running on Windows in about a day. I know for a fact they
spent months getting their shell scripts to run on Windows using the
emulator, with a *whole* lot more "if windows" branches than I have in
my Perl code.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
anti-advocacy advocacy Martin DeMello Ruby 21 09-18-2006 02:15 PM
Need Advocacy help? Brian Computer Support 1 01-25-2005 08:00 PM
Need Advocacy help? Brian Computer Information 1 01-25-2005 08:00 PM
Cisco Custome Advocacy Ivan Ostres Cisco 0 07-14-2004 07:29 AM
ANN: advocacy article: Why your organization needs Python Stephen Ferg Python 0 12-07-2003 04:13 PM



Advertisments