I think we've all seen this requirement before over and over again. Particularily when we work in multi-faceted teams where everyone comes from a different background and learned the language for various reasons.

My current contract is an investment bank with serious in-house perl experience. Yet the team where I am had never even heard of strict as a concept, did not use -T or -w, did not use any OO methods, did not have a working perl debugger working, and used CGI by seeding print statements throught the subroutines.

When I started here, I was appalled. I thought I had regressed to babyperl (thank you, monk who used the term on the CB yesterday, I'd give you credit if I knew who you are). Quickly I adjusted to the new problems I had to deal with, such as living in fear of scoping problems and willy-nilly use of local to make up for the lack of strict.

Here is the philosophy I approached in this case to cope with the situation:

    I am a contractor employed to:
  1. do what the client wants me to do within some ethical bounds
  2. add value to the price my client pays by providing the greatest amount of features possible.

Point 1) helps me remember that the client needs to be able to understand my work - like posting Monk is facing.

Point 2) helps me remember that it is sometimes a good thing to warn the client of the dangers of such behaviour as not using strict, and of the increase in effectiveness and portability that the client will enjoy from improving the team's adherence to general standards.

After 9 months on the job, we have finally managed to convince the group's manager (retired perl/sql coders) that better behaviour was good for everyone, and we now have fully strictified templates, and even managed to teach these old dogs about the benifits of templates and OO design.

Summary: We need to do what our managers want us to do. If there is a better, safer, smoother way to do it, we need to give a meaningful defense for that method, and see if we get a bite. But in the end, IMHO, we need not to try to force our own concept of standards down the throats of uninterested people faced with thousands of lines of well spaghetti-ized legacy code.

Hope this little story helps.

--Hackmare

In reply to Your client/boss is your (somewhat) god by hackmare
in thread to perl or not to perl by utopian

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.