Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Why our company doesn't use Perl :(

by Ovid (Cardinal)
on Feb 28, 2001 at 21:04 UTC ( #61351=perlmeditation: print w/ replies, xml ) Need Help??

So here I am, working in Amsterdam, wishing I wasn't stuck in VBScript hell. I asked my boss, after carefully explaining that I'm not trying to convert anyone, why he objects to Perl and prefers VBScript. He had two fascinating arguments:

1. The Netherlands is so strapped for programmers that the skill level required to use Perl is often not available. He thinks Perl is useful, but he can't guarantee that he'll get quality programmers. He believes that if he hires someone who doesn't know the in-house language, they can learn VBScript faster than Perl.

Now that's an interesting point. Frankly, I find that VBScript is much simpler than Perl and therefore easier to learn. Though "baby Perl" is simple enough to pick up, once someone starts getting into advanced territory, new Perl programmers may have a heck of a time keeping up.

2. He's found in the past (he has 27 years of programming experience) that Perl programmers are so "indoctrinated" in the TIMTOWTDI mentality that he's had a hell of a time imposing code standards. VBScript programmers, on the other hand, are "sheep" (his words, not mine) and easier to manage as a result.

What's your experience managing (or being a Perl programmer)? Are shop standards more difficult to implement? And yes, I've already read this article.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Comment on Why our company doesn't use Perl :(
Re: Why our company doesn't use Perl :(
by merlyn (Sage) on Feb 28, 2001 at 21:21 UTC
Re: Why our company doesn't use Perl :(
by jorg (Friar) on Feb 28, 2001 at 21:47 UTC
    The first argument definitely makes sense i think, working for a large multinational company i find that implementation decisions on IT projects are often (yet not always) driven by the available 'resources' in particular technologies ie people that master that technology.
    It makes sense from a financial point of view (bigger market means cheaper contracters) as well as from a support point of view (easier to replace resources, since IT staff is known to be easily tempted by a few bucks more!)
    IT managers are under constant pressure from the people on the business side to deliver so it makes sense for them to streamline and organise their processes as they see best fit in order to deliver the goods timely and in a way that complies to company standards. If this means coding in VBscript or whatever than that's how it's gonna be i guess.
    Everyone is just looking after no1 anyways...

    Jorg
Re: Why our company doesn't use Perl :(
by Elgon (Curate) on Feb 28, 2001 at 21:51 UTC
    I suppose I'd better give a little background on my learning Perl for this reply: I learned, or more correctly I started learning, Perl during a summer internship. I had relatively little recent coding experience except in VB, which was 1994-ish for a school project (A levels for non-'merkins).

    I have to say that I genuinely found Perl quite nice to handle: Okay, my first few programs looked like bad BASIC with C syntax but this is to be expected. In time I learned about 'coding standards', although I would call these 'standardised coding standards', mainly because I already used a series of my own devising. Most were in the style of indenting code in loops, map blocks and so forth: The first was, of course, use strict; at all times.

    The last rule, when boiled down to its essence, was that they didn't care too much what code standard we used provided that the code was easy to read and maintain and that there was plenty of commenting on the code itself: It must be noted that this kind of mindset, ie. "You've got a brain, use it!", tended to be fairly common. You were expected to just get on with it and use your common sense to know when to shout for help, rather than just ploughing on regardless.

    My conclusion is that provided that your code does things in a sensible manner, is secure and is readable and maintainable, imposing extreme or artificial coding standards can waste more time than it saves. I would guess that this depends on the standard of the coders involved.

    Just, as they say, my 0.02.

    Elgon

      Elgon wrote:
      My conclusion is that provided that your code does things in a sensible manner, is secure and is readable and maintainable, imposing extreme or artificial coding standards can waste more time than it saves.
      It would seem that way, but as an organization gets larger, you wind up with a much greater range of ability and style. This can have a significant impact on code quality and maintainability.

      Consider the following:

      • Bob decides that the best way to deal with a particular issue is to use a pseudo-hash. Hmm... well, that's an experimental feature. Is it appropriate?
      • Jane thinks that CGI has too much overhead, so she uses CGI::Lite. No one else uses it. Hmm...
      • Irving uses incredibly descriptive sub names like grab_the_headers_and_look_for_a_id_cookie(\@headers). Well, it's descriptive and he argues that it cuts down on documentation.
      • Sally hates having subs that require arguments be passed in a particular order, so she keeps writing wrappers for everyone else's code that allows her to pass a hash.
      • One of the coders I work with right now refuses to declare hashes. Instead, he always declares a scalar and makes it a reference to an anonymous hash. (%hash = (); versus $hash = {};). As an interesting side note, he's gotten in trouble for writing production programs in Perl :)
      Every one of the above programmers could make an argument for their particular coding practice. They may even be reasonable arguments. How do you settle issues like that? That's what coding standards are for: to remove that guesswork. I think that it does take some of the fun out of coding, but it does tend to ensure a bit of sanity in larger shops.

      Cheers,
      Ovid

      Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

        Okay, you've got a slightly different problem here. You need to encourage a culture of communication and idea-bouncing.

        It may help to encourage a discussion area where the team can asked stylistic questions and learn from each other's experiences.

        In one of my previous "lives," we held these during lunches, called these "brown bags," and kept them very informal. It took some time to get everyone on board, but eventually, we were all learning from each other and the resulting code because more consistent. You could still tell each person's style from their bits, but you could also see where the discussions had made a difference.

        I forget who said it, but one of the classics on software development practices notes that it takes ~18 months for an organization to move up a level in the Software Maturity Model. The same source also notes that each level must be met. This means it'll take roughly six years to move from a Level 1 organization to a Level 5 (world-class) organization.

        It may also help to ensure that each resource has time for research. Personally, I like to allocate 15-20% of my time to that, for if I'm not allowed to try things out, I can never learn new things except by experimenting with them in production code--which is a bad thing.

        Also, leave room for some disagreement and try to find the compromises.

        --f

        Ovid, it's a fair point:

        I agree with your point in general but footpad below makes some good ones too: There is a difference between a coding style making sense to one person and it making sense to a group of people who have, in essence, to peer-review the code when it needs updating.

        Bob, for example, is dead wrong unless there is an extremely compelling reason for using them: Some data structures just lend themselves to certain ways of doing things. Pseudohashes are, as you say, experimental and from what many have said to me, not the greatest tool in the world. In business situations it pays to code defensively.

        Ultimately, though, settling issues like that should be (IMHO!) by coder fiat: If your manager is a coder (mine was) and there is a dispute, they rule on it. Otherwise the most senior/competent coder (alpha geek ;-) rules on the issue, which, I guess ultimately leads to a coding standard, sigh.

        I certainly agree that life is different for small and large businesses: Where I worked (and will hopefully be working again this summer) is going through the transition phase.

        Cheers, Elgon

Re (tilly) 1: Why our company doesn't use Perl :(
by tilly (Archbishop) on Feb 28, 2001 at 22:07 UTC
    I have a possibly unfair impression here.

    You seem to be working in a company that makes decisions based on the availability of incompetents, that it wishes to treat as incompetents, and then justifies this on the basis of it being too hard to find and retain competent people. As a result when they get a competent person (you), that person finds it miserable and doesn't want to remain there. Thereby justifying their opinion that it is too hard to get and retain competent people...

    For the record I am a Perl programmer, working with several other Perl programmers, and we do a reasonable job of having code standards. Plus we don't seem to have trouble maintaining an (admittedly small) group of competent programmers. (We are a small company in a niche field and our primary job is analyzing bonds - not developing software.)

    Then again we chose people who were programmers first, and Perl programmers second. In fact we tend to hire competent people without regard to whether they know any Perl. We think we can teach Perl pretty easily. (And we don't just teach baby Perl either!) It is much harder to teach competence to someone who doesn't care...

      tilly wrote:
      As a result when they get a competent person (you), that person finds it miserable and doesn't want to remain there.
      Annoyingly enough, I have discovered a dilemma. Most of the companies that I have worked with that use Perl are small. However, I clearly prefer to work for larger companies. They are more likely to have documentation, project managers, procedures, etc. Smaller companies seem more likely to "wing it" and that's a recipe for frustration and failure.

      Damn. Never thought that I would think 33 is old, but I'm clearly a getting to be a fuddy-duddy. I want a bit of predictability and stability in my job. Sheesh.

      Cheers,
      Ovid

      Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

        Damn. Never thought that I would think 33 is old, but I'm clearly a getting to be a fuddy-duddy. I want a bit of predictability and stability in my job.

        Oh, to be 33 again ...

Re: Why our company doesn't use Perl :(
by footpad (Monsignor) on Feb 28, 2001 at 22:12 UTC
    Good questions and interesting points.

    To counter #1, keep in mind that the evolution of the Internet has made it possible to contract and work with developers in many countries. For example, a buddy of mine has sucessfully started a home based business working on contracts from clients based across the U.S. Heck, even my few clients are distributed.

    While this adds to the administration angle, careful management of the project helps reduce the risk for problems. As long as everyone is clear on the expectation and there are well documented tasks and deliverables, the process itself goes quite smoothly.

    To counter #2: that is an issue in any language and/or environment. There are C++ "experts" who zealously believe their personal ideas are paramount. Similarly, you will find, with little effort, VB/VBScript developers with the same attitudes. Even in my baliwick (Delphi), there are hard nosed people who will not open their minds to an alternate approach.

    It's up to the project lead to ensure that all resources are following the expected standards. One way to do that is to (loosely) tie compensation to behavior. Code reviews should be part of the approval/acceptance process. "It works" is not good enough. It must work, be clear, and meet all expected benchmarks--including documentation, standards adherence, and so on.

    That said, standards must not be straight-jackets. They must be flexible enough to evolve and to adapt for new information and/or ideas. Do not dictate trivial elements (number of spaces to indent, brace cuddling, and so on). Standardize the important stuff: consistency, a design for reuse, documentation, security, implemention direction, corner-case unit testing, testing requirements, and so on. Programmers will resist changes to their personal coding style, but the good ones will adapt to guidelines designed to make their code better.

    There is a creative element in programming and a good manager will seek out individuals that know when to think on either side of the box.

    Personally, I would ask your manager if he really wants "sheep" working for him. Personally, I wouldn't. I'm not afraid of having my ideas questioned; I encourage discussion, because software is rarely designed well in a vacuum. I am afraid of being slavishly followed, for I know that I don't know everything and I'm always willing to learn something new, even from an intern working on his first gig.

    These really are issues that should be brought up during the initial interview process. If he cannot get someone to open up and honestly admit whether or not they can work with his requirements, then he shouldn't be hiring them in the first place.

    Programmers aren't code monkeys and the wise manager will look for those who tackle all problems creatively, even the mundane ones such as following coding standards or keeping the schedule/budget in mind. (Not trying to say that standards are trivial, but that they're often used to bludgeon submission, which is wrong in my book. Standards are vital to a success development organization. Documented standards are even more so.)

    Your next step, my friend, is to see whether or not your manager has an open enough mind to explore the possibilities with you. His response to that will suggest your next course of action, e.g. can you work within the constraints he's laid out?

    (I know you you already know this; it's just a button with me because I've worked with good managers and I've had bad ones. The ones I've personally respected the most were willing to give my ideas a fair hearing and were willing to back down when they were wrong. Many stories there, but this post is too long as it is. *grin*)

    --f

    Update: Added the following for a minor bit of credibility:

    P.S. This isn't just the point of view of a JAPH or an "in-the-trenches" programmer. As (briefly) outlined in my home node, I have been a programmer, a tech writer, a QA tester, a support tech, a product manager, a consultant, and a team lead. I have seen many management styles and worked with many programmers. The styles that work and the people I respect are those that that understand, at least implicitly, the principles outlined in the Software Maturity Model.

    P.P.S. If anyone knows of a Level 5 organization in the Seattle area looking for help (or one willing to with with a Seattle-based telecommuter), please let me know privately. *grin*

Re: Why our company doesn't use Perl :(
by dws (Chancellor) on Feb 28, 2001 at 23:08 UTC
    VBScript programmers, on the other hand, are "sheep" (his words, not mine) and easier to manage as a result.

    This lit up my bogon detector.

    I once had a serious run-in with a manager who said much the same thing about a different technology. He was (in my jaded opinion) a Control Freak. It was very important to him to extert an aura of being in control. Managing meant getting the good little sheep to go along with procedures, though in that strange way that often seems to happen, the procedures had gradually lost relevance to the work at hand.

    Systemically, the affects were similar to what tilly described above. The good programmers got fed up and left, reenforcing his viewpoint that he needed to hire sheep that would behave. His department became an obstacle that the rest of the organization became creative in working around. The damage at that company took years to undo. (That company also had the codependent viewpoint that managers were to be supported in any argument with subordinates.)

    If you're in the position of butting heads with a manager like this, it's tempting to hold on to the particular technical issue that you're trying to win approval for, but that's really not the underlying issue.

    Ovid, if this is what you're running in to, I have a recommendation: Choose a font for your resume that faxes well. There are bigger organizations using Perl. They're just quieter about it.

(jeffa) Re: Why our company doesn't use Perl :(
by jeffa (Chancellor) on Mar 01, 2001 at 03:39 UTC
    Well, I worked my butt off today and of course I missed out on being on top of lots of good posts today. So, since everybody has beaten this topic to death some 7 hours later, I thought I would take a different approach.

    Ovid - I hate to say it, but those arguments are pretty damned valid. If I were in your shoes, I would stick it out - just because you are in Amsterdam. It can't be __THAT__ bad. Amsterdam!

    Let me tell the story of the pre-Perl jeffa - (crickets chirp lightly in background) . . .

    I started out after graduating with a CS major at a Mircosoft Shop as a 'consultant' where

    $truth{'consultant'} = 'junior programmer';
    I programmed in Visual Basic6, studied for MS Certifications, and thought I was doing OK. The Shop shopped me out to a client to finish a second revisioning of VB-Oracle app, originally started by a newbie VB programmer. If you think the code that newbie Perl programmers come up with is a bit convoluted, check out the VB newbies.

    Anyways, I worked on that project for about 3 months. Sometime around the last month, one of my fellow 'consultants' who was assigned to the same client asked me if I knew awk. I said, why not use Perl. So, next thing I knew, I had written a Perl script that parsed his data.

    The bug bit me. I hadn't written Perl in about a year. I remembered how powerful Perl was with it's regular expression engine brandished before it like a Paladin's Holy Sword.

    Two months later I found myself programming in Perl for a dot com.

    So, my point is: sometimes we have to do something else to appreciate how much we really love what we did. Ovid, think of having to program in VBScript as a catalyst that will make you really appreciate your next gig with Perl.

    And most importantly - enjoy your stay in Amsterdam.

    Jeff

    R-R-R--R-R-R--R-R-R--R-R-R--R-R-R--
    L-L--L-L--L-L--L-L--L-L--L-L--L-L--
    
Re: Why our company doesn't use Perl :(
by Malkavian (Friar) on Mar 01, 2001 at 16:40 UTC
    Interesting arguments from your boss, Ovid, but a couple of rebuttals spring readily to mind.
    The company I'm now working for is pretty much in commercial startup, although it's been developed for the last 7 or 8 years as a voluntary basis.
    The upshot of this voluntary system is that there is now 7 years of legacy code.
    At the time, it was the 'simplest thing' to get all the coders to use what they felt was the simplest thing to understand. Which worked for quite a few years.
    However, now the system is being looked at in the light of being expandable and efficient, huge holes have appeared.
    The simplest solution could only be expanded to do so much. There are now requirements that simply cannot be done in any even reasonably efficient manner, and now the whole thing needs to be redone from scratch (using a hybrid of Perl and C, with the whole thing being prototyped in Perl).
    Applying to the wider world (the team I work with also have the concensus that this is true from past experience), you have the options of having a shortsighted or long term solution to a problem.
    The shortsighted says: We want people to operate NOW. We don't want to have to train them. We will use the lowest common denominator as the default level.
    Often, using the simplest thing to understand quickly also goes hand in hand with very quickly reaching the ceiling of what is possible with that tool. Once that level is reached, further optimisations/advanced techniques are denied, without a ridiculous level of learning and technical knowledge, which is obtained by very very few.
    Using something slightly more difficult will have maybe a few weeks discrepancy in being operational at the simple level of coding (you're not going to be throwing in your newly trained coders to do your most sensitive programming tasks are you??). Once this initial concept is assimilated, the path from the simple coding to the very advanced is very smooth, with the ceiling of possibilities being much higher, resulting in the mid to long term of all your coders (resource to a company) being far more efficient and valuable.
    So, the choice is a matter of scope. You can have the 'instant gratification' with little long term payoff, or invest a little, and be prepared to wait a very short time, and have a high long term payoff.
    It seems that your company is going for the instant gratification method, and are thus, in the long term, limiting themselves.


    As a rebuttal to the second point (I have 21 years programming experience):
    There is ALWAYS more than one way to do it. It's not indoctrination, it's just the nature of programming.
    Given a task, different people will abstract the task away in a different manner, resulting in different implementations.
    That is just the way it is. It's not a Perl thing (although it's firmly stated in perl and allowed for).
    This is why Software Engineering was developed. That way, the 'more than one way to do it' for the system as a whole is removed. There is one way to do the whole thing.
    Interfaces are specified, internal tasks are handled in a specific way, and, in a well engineered system, the components are such that you can hand a task to a coder, and say 'this is what goes in, this is what comes out'.
    To be frank, you don't really care what method of implementation they use. You just want it to be fast, stable and efficient to the best of their abilities.
    In any language, the expert should code this in a different way to the novice. If that is not the case, then the expert is being artificially constrained, and years of experience in a company are wasted. They learn nothing, and the enhancement possibilities are wasted.
    The joy of the engineered system is that the component may be revisited in a future version, and enhanced with new knowledge gained by the coders to be more efficient and faster, while ensuring that the entity behaves as it should within the system as a whole. Over time, this can have a huge beneficial effect.
    So, in summation of this, the statement of flexible programmers being harder to manage to standards is a complete fallacy. In an efficiently managed environment, the flexibility of the coders is a boon, rather than a bane.
    If coder flexibility is a general problem, then the problem is more management laziness (hey, he's PAID to do the management to the best of his ability, not take the 'easy options' and cut corners to make his day easier) and lack of engineering/standards as a whole.
    Where there is a well defined problem/task, teams of very different people will reach a highly integrated solution. If the task is not well defined, then you're just looking for trouble no matter what language you use.

    Just some thoughts,

    Malk.
Re: Why our company doesn't use Perl :(
by Kickstart (Pilgrim) on Mar 02, 2001 at 10:36 UTC
    Does this mean we can't write obfuscated VBScript? :)

    Kickstart

      You can obfuscate anything. The projects we get to "finish" are always in very bad state. Bad design, unreadable code, terribly inefficient, totaly unreadable ... all in VBScript. I can asure you that I saw things that forced me to scream.

      Just a little example. The *&%@#(*$^%*#*&&#^$% was using three variables j, k and l throughout the whole page, then passed them to the next page, and used again j, k and l, but the meanings were exchanged. What used to be k was now l and vice versa. Bleargh. (In the end none of those variables were needed. The design was bad.)

      On another page they first wrote the posted data into a file, then made a few useless obfuscations, read the file back in and processed the data. Of course the name of the file was static and there was no locking. But it took a few hours to decipher the code only to find out 90% is worse than useless.

      Generaly I think that the quality of the average VBScript code is much worse than the average Perl. Because "just about anyone can write VBScript". So often people not only without education, but also without brains spit out horrible VBScript for living.

      But the management is happy ... if the boss looks at the code he doesn't see any strange characters, there are normaly looking english words, it all looks readable ... until you try to read it.

      Jenda

        I just take one look at this code, throw is away, and rewrite the whole thing. Rarely is it worth all the extra time to decipher it and maintain it in the future.

        Sadly, many managers do not share this opinion.

Re: Why our company doesn't use Perl :(
by Odud (Pilgrim) on Mar 21, 2001 at 05:43 UTC
    Where I work there are two real Perl fanatics, me and Mike. Well we can use Perl to do almost anything, quicker, faster, better than any other language coders you can name. As an example I last week I wrote a Perl script that did in ~700 secs what was estimated to take 20hrs (by hand because the infidels said it couldn't be scripted).
    The problem really is that (seen from the management side) if they take one of my scripts and show it to joe_random_coder he says it is indecipherable (despite the liberal comments and that fact that I can produce a man page and a HTML doc directly from the code) and that is good enough for them. I shouldn't have to feel guilty for his lack of ability!
    Keep going with your head down, produce good code - quicker than they can, easier to amend; and one day the penny will drop.
    Don't forget that at the moment 95% of the grey suits have only just forgotten the old edit, compile, link, run COBOL methodology. It's going to take them time to accept the new religion - all we can do is to make their path easier
Re: Why our company doesn't use Perl :(
by PetaMem (Priest) on Mar 21, 2004 at 15:24 UTC
    Hi,

    I understand his arguments and in fact think they are very valid from his perspective. Let me explain that in more detail:

    • I've met "really really bad" Perl coders. They were quite experienced in Perl and their craft was often nontrivial. So why were they THAT bad? Well - they thought they were very good. They were intelligent, they obviously knew (or thought to) that they "master" an extraordinary language, so they felt like XPs.

      What happened? Most of these guys were young and had no experience in larger scale projects. They virtually laughed at requests like commenting code and programming cleanly, using a certain indentation and set of idioms. In that sense, the 2nd argument of your boss was right.

    • But in my opinion this problem applies only to young wild Perlies AND to (project) managers that are not strong enough to either persuade the Perlies for the necessity of discipline or to take the bitter consequence to fire a young programmer that could develop into a real elite if only he had more insight.

      Then again, this also supports arg 1 of your boss.

    • Perl is complex. To harness its power in large scale projects needs many things: good people (skill, discipline) both at the programmers and the project managers side, the WILL to solve problems and the bias towards elegant technological solutions, i.e. not only programming to solve something, but to program to solve a problem ELEGANTLY too. Especially with perl. This is very contrary to most perl scripts out there because Perl often serves the glue/guick'n'dirty paradigm!
    To sum up: I think your boss is right, because his needs are probably technologically not THAT rocket science, but it is utterly important that the jobs get done.

    Then again, if you feel different about this, you're in the wrong company.

    There are companies, that wouldn't touch VBScript even if they'd need to fly the right Perl programmers in from all over the world.

    Bye
     PetaMem
        All Perl:   MT, NLP, NLU

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://61351]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (4)
As of 2014-08-01 04:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (256 votes), past polls