Unfortunately, I am very bondage-and-discipline when it comes to project management, partially because I work for a large consulting firm and am used to working on very large projects with many coders of widely varying ability, but also because I have a very logical mindset about this sort of thing. If any of the advice which follows clashes with your style, please feel free to use it or disregard it completely as you deem appropriate. This ties in with my first principle;

1 - Be consistent where possible, but always manage to the appropriate level.

For a big project which is to be handed over to an external client, it makes sense to go for the full-on document-everything-and-get-signoff approach. On the other hand, if you've only got two developers and one deisgner working for you on a small internal gig, then a simple one-page spec may well be the ideal way of communication, with much of the more detailed documentation being in code comments.

The logical end point of this rule is that you may ignore any other rule or create any new one, provided that it is the right thing to do.

2 - Keep all of your emails and all of your documentation in a central repository for later reference.

This comes under the heading of covering your arse, which, however unfortunately, is a very necessary evil of being a project manager. The ability, when challeneged, to be able to pull out an email which covers the main point of contention is invaluable. Ideally all of these would also be kept under RCS.

Also remember that documentation isn't for you or your team members. It is for the people who have to use and support the tools that you build. Even if this is your team, just remeber that in five years time, when your widget is still being used, it is highly likely that you and the rest of your team will no longer be there.

3 - Set a few simple design standards.

These will vary, but given that you're talking about Perl specifically; An example principle would be something like "Any function which is used more than twice in a script should be declared as a function" or "Any function which is used more than twice in different scripts should be included in a library module".

The most important design principles of them all are - "Use some common sense" and "Keep it simple, stupid."

4 - Set a few coding standards.

As above with design standards, coding standards will also vary according to your preference. For Perl, I would suggest that use strict; and -w should always be the case, except where there is a good reason not to. Make sure that your coders don't break APIs when they "fix" things.

5 - Revision Control

Use it and make sure that version control discipline is enforced. There is nothing more irritating than finding three different versions of the same code, each with slightly different filenames in the same RCS. Forking hell!

6 - Deadlines and Caveats

When asked to give work estimates and set deadlines, give a possible overrun and state all boundary conditions. Sadly, this also often comes under the covering your arse heading, and people want what they want yesterday and for free. Unless you wish to blow your time and fiscal budgets, make sure that the people for whom you are setting the deadlines understand a) that there is an error factor involved, and b) that if they change the spec then the deadline is also going to change.

Task = Time * Resource

This equation is not generally mutable for programmers and managers of given skill, so you can't just double the size of the task without increasing the Time taken and/or the Resources available.

7 - Testing

For every hour of time spent on actually writing code, you're likely to spend a day on writing or executing tests. This is a pain and only the truly anally-retentive enjoy testing, so try to automate as much of the process as possible. A couple of point on testing generally...

• Test negatively as well as positively
• Unit test each component
• Test all of the components in an assembled state, but don't just rerun all of your unit tests again
• Use realistic test data
• Use realistic volumes of test data

Just a few suggestions, and as I say at the beginning, please feel free to implement or discard as you prefer. Good luck.

Elgon