The project had been in discussion for 18 months, going through the prioritization, budgeting, overall design, and other administrative processes endemic to large corporations and their resource planning infrastructures. The original developer assigned to the task had, during that time, left the company. Due to other changes going on, so had the backup person.

This meant that there was one person left who had any interest or experience (heh) in writing CGI scripts. Me, who doesn't even belong to IT or IS. (I work for Marketing, which is another story itself.)

Thus, the project was dropped in my lap with a two week deadline. Naturally, I have zero access to the servers hosting the company's CGI scripts. Also, this is my first "real" Perl project.

I cobble something together within the deadline, test it on the server hosting my personal websites, and submit it to TPTB. Yay...successful completetion, right? Hah.

The project sponsor does some testing, asks for some enhancements, and starts trying to get it deployed on the company's servers. I quickly make the changes.

Interlude: I find the Monastery and begin to learn just how awful the original implementation is. I desperately want to rewrite it to make it better.

Three months later, Corporate says they're ready to test. And, oh, could I make a small change? Sure, no problem. Done, documented, zipped, and sent. I'm also able to slip in a couple of key changes. Lots still to do, though. But, I leave it alone as it at least works.

Four months after that, Corporate asks where the files are. I tell them I already submitted, but here's the ZIP file again, just in case something happened in transit.

In January, the new Product Manager asks me to attend a meeting on getting the project finished and deployed. (The original sponsor having left the company some six months before.) I attend, finally learn who all the players are, and am finally able to talk to the actual administrator who's just been hired to handle this stuff.

He asks, "What do I need to do to deploy this?" "Well," I say, "if you check out the README file, there's a pretty detailed list of configuration changes that you'll need to make, since I didn't know the names of the servers and no one wanted to tell me." (Okay, I was a little more diplomatic than that, but...that was was gist.) While we're discussing this, I hear confusion in his voice.

"Tell you what," I offer, "why don't you give me a week to see if I can't make this easier on you? This will give you some time to install some CPAN modules you'll need. There's a list in the README."

"Okay," he says. "That'll be fine." We tell the product manager and I finally have some time to make the improvements I've been wanting. Yay. I'm happy.

I clean things up, separate the configuration, add file locking, etc, etc. It's much better. I revise the documentation (ripping out some ten pages in the process), package things up, and send it off. I feel much happier thinking that the script is closer to what we like to see in such things within these walls.

Things languish in limbo for a time, in part because the Product Manager goes on extended vacation without telling the rest of team. I keep tweaking, just in case another chance to update appears. One does; I do so. It's still not perfect, but it's defensible. Once again, I revise the docs and sent it off.

A month later (today), I hear the Admin has finally gotten the modules installed and that we're finally ready for testing. ("Excuse me?" I want to scream, "Haven't you heard of -MCPAN?" I restrain myself...barely.)

During the same meeting (a conference call split across three cities), I observe that the:

1. Product Manager has no clue who's responsible for what or what needs to be done to do it.

2. Server Administrator has run into problems without consulting with Development (me). Furthermore, he blows off all meetings regarding the project.

3. Security Administrator knows how to implement .htaccess and SSL, but has no idea how to deal with Perl or CGI scripts.

4. HTML Designer is capable, but powerless because he has to beg Security for the URL's, server names, and other administrivia needed to connect a link to a CGI script.

5. Development finally gets authorization for shell access to the deployment server.

The morals of the story are many, as are the mistakes (including many of my own). However, this is worse than any Keystone Kops flick or Fox "reality" show. Please notice the ones relevant to your work and take steps to avoid these types of problems.

Here's the main ones from my point of view:

• Foster an environment of communication.

• Clearly document (and make available) the names, phone numbers, email addresses, and responsibilities of the team members--especially if you're working with other teams that are not located in your offices.

• Give people very clear guidelines of your expectations and needs.

• Don't be afraid to ask for help, nor to kick some fannies to get things moving.

• Give your people the training they need to do their jobs properly. At the very least, when approached by someone who wants to help with any problems, take them up on the offer.

• Don't get so paranoid at avoiding social engineering that you exclude internal people trying to learn and work with your security practices.

Sorry...I just had to rant.

--f

P.S. I got dinged on my performance review because this project is now a year late. No matter that I had my piece completed on time and under budget. G-r-r-r-r-r...!