Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Programming Department

by danambroseUK (Beadle)
on Jan 14, 2006 at 19:03 UTC ( #523210=perlquestion: print w/replies, xml ) Need Help??

danambroseUK has asked for the wisdom of the Perl Monks concerning the following question:

I work as part of a small programming team, creating small and medium sized web based systems - perl mysql etc.

As part of my job, I am putting together a proposal to make the department better, more efficient and more able to cope with handling larger more complex projects.

My ideas currently..
1. Implimentation of Source Control
2. Company Programming guidelines - (based on the perl best pactices book)
3. Set up bug tracking system such as Bugzila to handle debugging of larger projects.
4. Code audits, check each others code to ensure that they are conforming to point 2, and also ensure efficiency, on a regular basis.

Do you guys have any other ideas, or examples of what you do to ensure a happy, stable, scalable programming team!?


Replies are listed 'Best First'.
Re: Programming Department
by qq (Hermit) on Jan 14, 2006 at 19:53 UTC

    Consider Trac. It combines a subversion repository browser, wiki and tickets for bugs and feature requests. It's not as sophisticated as some systems (lack of dependencies between tickets is a big problem). But the integration is well done and the interface pretty. See Catalyst as an example.

Re: Programming Department
by g0n (Priest) on Jan 14, 2006 at 19:55 UTC
    A few more suggestions

    • Documentation standards (& possibly templates for the documents)
    • Version control of documentation as well as code
    • Testing guidelines & standards
    • Peer review of designs.


    "If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."

    John Brunner, "The Shockwave Rider".

Re: Programming Department
by perrin (Chancellor) on Jan 14, 2006 at 19:47 UTC
    You might find these slides from a talk by Michael Schwern interesting.
Re: Programming Department
by ides (Deacon) on Jan 14, 2006 at 22:40 UTC

    One thing most people overlook, that I find extremely useful is to build EVERY application or library as if you were going to release it to CPAN. This has several advantages and takes almost no extra time once you get used to it. The main advantages are:

    • You can leverage the existing install infrastructure to automatically handle dependicies for you.
    • In your dist you can hold all of our associated documentation, database schemas, cron scripts, etc. all in one tar.gz.
    • As one of my co-workers just started us using, you can use CPAN::Mini to help install applications and/or libraries on multiple servers easily.
    • It makes each app consistent. You know what you'll find in bin/, in docs/, in sql/, in lib/... no surprises and it makes the programmer who has to maintain your code a year from now ( which is btw most likely you! ) have a much easier job.

    Take a typical web app, you've got your Perl code, your database schema, your configuration information, and probably at least a few cron scripts.

    By using something like module-starter and Module::Build you can automatically install your templates in say /usr/share/web-templates, your cron scripts into /opt/app/cron/, and drop your configuration into /etc/httpd/conf.d with a simple make install

    If you aren't familiar with either Module::Build or ExtUtils::MakeMaker then there is a bit of a learning curve, but once you learn how to use these modules effectively, doing this adds a very trivial amount of time to each app and/or library. Trust me that once you start using it, you'll never want to work in an environment that doesn't.

    Frank Wiles <>

      Conversely, if you have no intentions of releasing your code to CPAN, you may decide to avoid the nightmare of the unnecessary, undocumented, unarchitected, unfathomable, unmaintainable, over-elaborate, rotting festering mess that is ExeUtils::MakeMaker completely.

      And for anything you do have a hankering to release to CPAN, spend an hour or two trying to understand what the hell is going on when you run the for any moderately complex CPAN module, and try to imagine the trouble you are going to have to incorporate any extra customs steps.

      For example, say you would rather have your build process extract the files directly from your source code repository? Rather than having to do this as an extra manual step, with the inherent weakness of forcing the duplication of your source tree and/or imposing the convoluted pattern that is the 'blib' phenomena upon your source tree structure. Look hard and think very carefully how you would modify EU::MM to do this?

      Of course, I (infamously) do not have any CPAN modules to my credit, so I may be just crying wolf, so I urge you to look at and think about the problems this route would cause you. Also, take a look around at some of the comments made about the ExtUtils::MakeMaker module by it's current maintainer.

      And if the Module::Build route looks interesting, have a good look around at the internecine struggle between it's proponents and the EU::MM diehards.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        I find the typical Module::Build opponentís argument that itís not mature and wonít be for a long time to be quite disingenious. Only software which has users improves. The argument that you inflict pain on users is understandable, but for simple needs you can avoid that by way of create_makefile_pl => 'traditional'. And while users complain that there is no compatible PREFIX support, I always found it a mess to deal with as a user and applaud the coming of install_base.

        The other option is Module::Install, which for some reason I canít bring myself to like, even though everyone using it seems to rave about it. Last I looked, I couldnít find much documentation, anyway.

        Makeshifts last the longest.

        Yes, you're crying wolf.

        Forget EU::MM and Module::Build and just use Module::Install, which wraps BOTH of them as needed and makes writing installers almost trivial.

        You example is bizarre... you only need to store the actual modules, the blib stuff (which is used for compiling and so on) only exists between when you run Makefile.PL and when you run make install. It never goes anywhere near the repository

        As for doing things from the repository, we just use...
        svn checkout http://..../project cd project perl Makefile.PL make make test make install

        My intent wasn't to promote ExtUtils::MakeMaker, I too have found it hard to work with for complex tasks, which is why I now use Module::Build and am going to be taking a hard look at Module::Install in the near future.

        I also think you misunderstood most of my post. There is no duplication of your source tree, and no blib weirdness. Your source repository for a particular app *IS* your build environment. There is no need to have your build process checkout the source, your simply build a dist in your working copy.

        To give a detailed example let's say I have a mod_perl application that I'm building called 'Foo'. I start off my application with module-starter and it creates the Foo/ tree for me with a lib/ ( where your code goes ) and the other various elements we're all accustomed to.

        Once I've put in stubs for all of my various modules, Foo::Main, Foo::Admin::*, Foo::Model, etc... I then check this entire structure into my revision control system ( I use subversion ) and I'm done.

        No blib weirdness ( incidentally this directory is only created when actually install your app ), no duplication of my source tree, no convoluted patters I can think of... unless of course you prefer to just drop everything in some very large directory without any organization.

        Frank Wiles <>

Re: Programming Department
by dragonchild (Archbishop) on Jan 14, 2006 at 21:37 UTC
    Get as many of these as you can.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: Programming Department
by astroboy (Chaplain) on Jan 14, 2006 at 21:42 UTC
    If you can convince someone at work to invest in dead tree doco, have a look at Rapid Development by Steve McConnell for project best practices. (His Code Complete 2 is an excellent guide for programmers too). And if you still have money in the kitty, check Under Pressure and on Time (no, I don't work for Microsoft Press ... these are all really good books!)
      I'll second that. Under Pressure was a very good book.

      Code Complete should be required reading for every single programmer, regardless of how long they've been at it.

      I've been programming for 20+ years and still found CC to be a great book. A lot of good tips/suggestions/reasoning in there, and very good explanation as to why those recommendations are what they are.

      It doesn't need to be followed to the letter, but there are some major Best Practices in there, allowing you to choose and follows the ones best suited for you and your organization.

      I read the original and actually would like to go back and read CC2 now, just to 1) Get some more info and 2) see what new changes are in it.

        Under Pressure is out of print now I think but you can still buy it used on Amazon for super cheap. I thought it was definitely worth my time spent reading it.
        The poster actually did, just without links
        2. Company Programming guidelines - (based on the perl best pactices book)
        But it is definitely a good book and the links to it are good things.
        Squibbie Pooh Ski Doo.
Re: Programming Department
by jthalhammer (Friar) on Jan 15, 2006 at 07:36 UTC
    I'd suggest looking at Perl-Critic. It's a static source code anaylser based on Conway's guidelines. By using Perl-Critic or Test-Perl-Critic you can solve a lot of your consistency and quality problems with almost no effort!


Re: Programming Department
by CountZero (Bishop) on Jan 15, 2006 at 20:14 UTC
    Extreme Programming with Perl is certainly worth reading if you want to expand you business.


    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

      I like XP too. :D

      I must admit that I'm still not using any of it. Just picked up a book about it few days ago. And many (basically all) things simply make sense.

      Of course, I tried some things that it promotes on my own, before I even heard for XP. Like Pair Programming. I used that a lot on programming labs in High School and College. It works exactly as they say - two heads are better than one. One thinks locally (one that is typing the code) and the second thinks more globally while also checking for typos and doing other tasks like paperwork ...

      Too bad I'm working as a freelancer so some of XP stuff simply wont work :(

      Have you tried freelancing? Check out Scriptlance - I work there.
      I am big fan of XP as well. At the very least, writing tests is *extremely* helpful, especially as your team grows.
Re: Programming Department
by DrHyde (Prior) on Jan 16, 2006 at 10:14 UTC
    Lots of good advice from people, but no-one has mentioned the biggest one - that is that you can have all the guidelines in the world, they won't do any good unless you make sure they are followed. That is a matter of managing people, and is Hard. In particular I have found that it is difficult to enforce regular code reviews.
      Oh so true ... You may know a lot of things - like when you are reading a book you say "Boring - I know that.". But the real question is not if you know (about) it.
      The question is: "Are you using it?"

      In particular I have found that it is difficult to enforce regular code reviews.
      But XP folks thought about that too :) For instance Pair Programming is a way that ensures a constant code review ...

      Have you tried freelancing? Check out Scriptlance - I work there.
        Thanks for the quick replies - I have ordered a couple of the books mentioned, so that I can swat up on the best way to approach the task of getting my department upto scratch. I am keen to put in some kind of monthly interpersonal code reviews - where by each member of the team reviews the others code to ensure that it follows the agreed standard, and suggest improvements etc.

        My question is how do i put this into action with minimum resistance, certain members of the team i feel, would be resistant to change, and not so keen to better themselves/ their code, even though it is for the best.

      With CVS (not sure about other source control systems) you can add a hook during checkin that requires the name of the reviewer in the checkin message. Not foolproof of course, but certainly better than nothing.
Re: Programming Department
by glasswalk3r (Friar) on Jan 16, 2006 at 16:09 UTC

    I would add to your list the use of PAR and CPAN::DistroBuilder modules to help on packing your applications.

    Alceu Rodrigues de Freitas Junior
    "You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://523210]
Approved by K_M_McMahon
Front-paged by Tanktalus
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (5)
As of 2023-12-11 10:20 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (41 votes). Check out past polls.