Larry said:
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
