Perl contract problems

[blackadder]

Hi All,

I have sort of problem or dilemma.

This is my first Perl developing contract. I have been in this company for approx less than 4.5 months. Initially it was a 3 month contract, and then at the end of the 3rd month, it was extended to another month. Off course I wasn’t happy with this arrangement, but there wasn’t anything I can do about it.

My boss has asked me to give him the source code to an application that I have developed – that the full cycle, from the concept, design, coding, testing, documentation and deployment. The problem is he has also have asked me to comment every single line the code. He explained that he needs to know what every single line does, by the way he is not a developer nor had development background.

Before I began to work for them, they had lots of accounts access permission problems. Their inapt and useless helpdesk supervisor has assigned the ‘Everyone’ account full access to literary every where (server/drive/share/everything) in the organisation. So, to tackle this problem, they employed a project manger, who in turn has employed a number of assistance and helpers. A year and half down later, nothing was done. The reason was because Microsoft’s Cacls can’t do the job, therefore they require a Perl programmer.

Enter yours truly, as a resource to develop a tool for the 3rd line support guys to use intsead of M$’s silly Calcs command. This was done, with a great help from PM, within the first month.
Next, they came back and said they would like a GUI interface for the application because it going to be used by the help desk staff so in my boss’s own words “The package must be idiot proof”. So there I went, and programmed a Perl /TK based GUI interface. They came back again and said “right we would like all the information to be piped into a database”. No worries I said, and in come the ODBC library, and programmed it so they can dump the data into a database.
This wasn’t enough, they cam back with a demand (can’t say it was a request), to put all the scripts that I have written into one application. My idea was very original and have went out of my way to ensure that the application is of top quality , almost idiot proof, very user friendly…etc. and they liked this application/script a lot.
More requests came in to add more facilities and functions to the script, in other words ”they kept moving the goal post”, the goal post are so far apart I can’t see any of the posts anymore.

Now, the contract is coming to an end. OH yes by the way, because they have never ever seen Perl or what it can do before, nor they ever had any 3rd line support staff with any sort of a scripting experience, they were absolutely mesmerise (I think) with my scripts. Unfortunately, this did not do me any favours with the current 3rd line support engineers and progressively I became very unpopular with them. It seemed that the more I wrote better scripts to automate support task, the more hostile they turned?

My question is; having given them the exe version of my script and full user manual for it, can they request/demand that I should comment every single line, because, well it is obvious, that they can simply bring someone else, give them my script with every line is commented so they can do what ever to it, own it, reap the benefis…etc. can they do that?

Nothing my contract explicitly says that I should comment every single line of my code before I leave so they can bring any Jerko to take over the script? Can they?

Many Thanks for listening.

[Elgon]

Hi blackadder,

Well we have all got our knickers in a twist here, haven't we? The technically correct, but not necessarily useful, answer to your query is 'it depends.' Not very helpful I agree but read on...

As has already been noted, unless you put in some nasty clause into the contract about the IP rights to the code belonging to you, all modification must be done by you or your authorised representative etc... then they can do whatever the hell they like to the code, either themselves or via another contractor and there is very little you can do about it. BUT they cannot force you to do anything to the code that you haven't included in the contract - provided that you've reasonably commented the code in line with good development practice - unless they have some kind of leverage, non-paying of bonus, witholding other forms of payment etc...

This leaves you with several options...

• Finish the job and comment the code - Okay, mybe the support guys don't like you but at least everyone ends up happy and you end up with the money for the time taken to do the additional work. (You did put in a clause about any changes in the requirements being subject to additional charge, didn't you?)
• Tell the boss to get knotted and leave - unless you've let them get some kind of leverage over you, you can do this and still get paid (probably.) The downside of this is that if you've overlooked something then you could get sued.
• Try and reason with the boss and explain to him why commenting every line is pointless - Okay, I'm going out on a limb somewhat here but I'm including it for completeness' sake.

Personlly, I'd stay and comment the code: This should at least engender some goodwill from the PHB and will keep you in gainful employment for a while longer. If they really want to give some other muppet the code to ply with, they will anyway - this way they will at least consider asking you to come back and do the job (if you want to...)

Lessons...

• If anyone is going to get it in the arse, don't let it be you - get a lawyer to look at all contracts and think about things like bonuses, extra charges for change requests and so forth.
• Sometimes people break contracts - have a contingency plan: they might just not pay you your bonus for just such a reason, carry a loaded lawyer at all times just in case.
• Be totally anal about your contracts - this way you'll hopefully have all the bases covered.
• This is why most software comes with a EULA which reads like the Warsaw Convention
• If it does come down to court - the only people who ever win will be the lawyers.

The main point here is that the contract should clearly state what the expectations of the company are and what should constitute a reasonable fulfilment of these criteria. That way if things get nasty, chances are that their lawyers will tell them to settle out of court.

Elgon

PS - IANAL, usual stuff about not being held responsible for believing me yada, yada yada.

"What this book tells me is that goose-stepping morons, such as yourself, should read books instead of burning them."
       - Dr. Jones Snr, Indiana Jones and the Last Crusade

[VSarkiss]

Well, if you're at the point of "my contract doesn't explicitly say", the relationship is probably, although not certainly, beyond repair.

As to your questions:

Should you provide the source code?

Absolutely. In almost every case -- employee or contractor -- the code belongs to the company, not you.

Should you comment it thoroughly?

Yes, to the best of your ability. You owe your client, jerk or not, nothing less.

Should you comment every single line?

Point out that it'll cost time and money to do that, and if they still want it, yes, do that too. However, try to talk to your client in a non-adversarial way, and see if they'd be OK with a block of comments before every logical section.

There's not enough to tell why your relationship has gone so sour, but I can venture some guesses.

• You may have been in the middle of competing managers or alienated organizations. In this case, there's absolutely nothing to do, except learn how to read the client dynamics better for the future.
• Was your own attitude "you dummies need me" or "the customer is always right"? (The tone of your note reads like the former.) Remember you're there to provide a service. Nobody likes a PITA consultant.
• When they asked for changes, did you discuss it with them beforehand, or just start coding it up? Usually you have to consider who's asking for it, how will it affect the system, who will pay for it, etc. Otherwise you end up trying to dance to several tunes at once. This is also related to learning to read the client organization's dynamics.

In any case, it sounds like you should chalk this one up to experience. Try to leave a good relationship: contracting is a small world. You'll probably encounter these people again, so try not to piss them off on your way out.

[metadatum]

well it is obvious, that they can simply bring someone else, give them my script with every line is commented so they can do what ever to it, own it, reap the benefis…etc. can they do that?

Unless specified in your contract with them, THEY own the code, not you - so yes, they can do whatever they want with it.

Welcome to the world of contracting.

[sschneid]

I agree. If they're paying you to do something, you basically do it, or you don't get paid. You don't own the code, the company you're contracting for does -- if they want it a certain way, you're pretty much obligated to make it that way. If the boss wants code that has every line documented, and you refuse, I can bet he won't be keeping you around for too long (as unfortunate as this particular situation is).

scott.

[diotalevi]

I think these points are missing an important point that as a programmer it is part of your professional obligation to help create the requirements that you'll be working under to ensure that they are do able, make sense and will benefit your client. The way the original poster worded things it sounded as if things were completely out of his control. Obviously that's not true in any reasonable situation - I you were my teammate then I'd expect you to push back on things that don't make sense and help to guide things appropriately. Things still can still go badly but at least you'll have exercised your obligation to do a good job which is a larger issue than just having good code.

[diotalevi]

You should document it so a competent Perl programmer can understand it and then leave a copy of O'Reilly's Learning Perl. Your supervisor isn't going to be the one patching your project - he doesn't know perl. If he *is* doing that then I know where to find one supervisor that is wasting his time. Your documentation may include pictures, strategy documents, revision histories or whatever else is needed to encapsulate the higher-level order to the application. Lower level things should be documented inline unless you think it's important enough to document separately.

There's no magic here - an $Language programmer is required to work with $Language programs.

[RMGir]

I'd suggest talking to a lawyer. Not so you can sue your counterparty, but so you can find out what your rights are in your country, state, and municipality, and what theirs are, under the exact contract you signed.

The advice you get here may be somewhat enlightening, but "Perlmonks said so!" isn't a legal defense. :)

We're not lawyers (I certainly am not!), we don't know what your local laws are, and even if we claim we're lawyers AND knew your local laws, you can't say to your local bar association or better business bureau "RMGir gave me bad advice!" and expect them to know what to do about it, can you? :)

I'm sort of leaning towards "you have to leave the source code", as everyone else is. But it really depends on your contract and the local legal situation. And HOW MUCH you need to comment that code is probably also quite variable.

If they're paying you for a few days or weeks just to prepare the code for transition, why not?

But if they expect you to comment it on your own time after the contract's over and then hand it over, that seems less reasonable. In that case, if you do have an obligation to hand in the code, I'd hand it in as is. I wouldn't advocate obfuscating or disabling the code you hand in. You only ever get one reputation.

Even if you don't come away from the job with the source you wrote, you DO come away with valuable experience, and you CAN come away with a good reference from a satisfied customer; that could be worth more to your career than the code is...
--
Mike

[Zaxo]

Now is the time to speak of support contracts and follow-on work. You know their code and they have nobody to maintain it.

Make sure there is a read-only cvs backup of the final code and keep one yourself. Make them a working cvs for maintainance.

Make an md5 digest of everything, and document them on paper at signoff.

After Compline,
Zaxo

[dws]

My question is; having given them the exe version of my script and full user manual for it, can they request/demand that I should comment every single line, because, well it is obvious, that they can simply bring someone else, give them my script with every line is commented so they can do what ever to it, own it, reap the benefis…etc. can they do that?

Yes, they can. This is a contract. They can ask for whatever they want. Again: They can ask for whatever they want. It's up to you how to respond. You can plead "out of the scope of my original contract," but don't expect themt to be happy. By saying "the goal post are so far apart I can’t see any of the posts anymore", you suggest that you haven't kept a written record of what they've asked for, in a form that you can point to.

Part of the game of contracting is scope management. You'll get asked to do things. You need to reflect back set of estimates that they can prioritize, and you need to keep the prioritized list visible. They'll add new stuff. Give them an estimate and let them reprioritize. At any point in the game, you need to have a prioritized list. That's how you keep the goal posts visible.

You also have the ability to counter any request that they make. In the "comment every line" case, you could counter with "comment every block of code", or "comment every function, and anything non-obvious going on within the function." I'm guessing, based on past experience, that they might not have really wanted a comment per line, and might gag if you hand them such. It sounds like these guys aren't masters of clarity when it comes to asking for what they want and following through on it.

[charnos]

Disclaimer: I know NOTHING about contract work. However, I'd be inclined to say, yes they can. It's quite unfortunate knowing you have to give up your baby (I can sympathize), but I personally don't see any logical way around it (logic is not always present in law though ;)). I see this for two reasons:

• Firstly, outright disobeying their request would probably be in violation of your contract. That's generally not a good thing.
• When you work on a contract basis (I'm pulling this from tilly's Works-for-hire node), everything you work on for the contract is under their ownership. That being said, it's probably at their discretion what a "quality product" is. Unless your development contract explicitly says that you do not have to document the code, it's probably their decision what degree of documentation you must provide.
Also, if your argument against doing it is that they'll simply keep modifying the code as their needs change, that's not much of a leg to stand on. As stated earlier, anything in the contract is theirs, they can modify it however they want once the contract is over.
Thank *you* for the insightful post, and best wishes in your endeavour :)

[jdavidboyd]

You state "Of course I wasn’t happy with this arrangement, but there wasn’t anything I can do about it. "

Why wasn't there anything you could do about it? What kind of draconian contract did you sign? You had no choice about it being extended for more time?

At least, you've learned to take more control of what goes into the contract that will rule your life and work.

Dave

[talexb]

This is my first Perl developing contract. I have been in this company for approx less than 4.5 months. Initially it was a 3 month contract, and then at the end of the 3rd month, it was extended to another month. Off course I wasn’t happy with this arrangement, but there wasn’t anything I can do about it.

Odd.

Why did you stay if you weren't happy?

My boss has asked me to give him the source code to an application that I have developed – that the full cycle, from the concept, design, coding, testing, documentation and deployment. The problem is he has also have asked me to comment every single line the code. He explained that he needs to know what every single line does, by the way he is not a developer nor had development background.

Well, there's no need to take him literally: you probably don't need to put a comment on each line. However, you probably do need to write a comment block for each group of lines.

Here's some recent code of mine:

  #  Get the Form object and collect the variable 
  #  information as submitted.
  
  my $Form = new CGI;
  my $Vars = $Form->Vars;
  
  #  Encode apostrophes so MySQL doesn 't worry.
  
  foreach ( keys %{ $Vars } )   
  { 
    $Vars->{ $_ } =~ s/'/\\'/g; 
  }

I don't have every line commented, but the comments are frequent enough that I feel it's sufficiently documented.

More requests came in to add more facilities and functions to the script, in other words ”they kept moving the goal post”, the goal post are so far apart I can’t see any of the posts anymore.

This is a problem? It sounds like they loved your work and because you were working out, they wanted to add more functionality. That sounds like a win-win situation to me.

Nothing my contract explicitly says that I should comment every single line of my code before I leave so they can bring any Jerko to take over the script? Can they?

Yes, they can bring anyone in to work on the script you developed. You're under contract to them, they own whatever you develop for them.

Now, if the new guy calls up asking questions, be helpful for the first 15 minutes, but after that you can suggest that your time is billable and perhaps the new guy should get the client to authorize payment for some of your time.

--t. alex
but my friends call me T.

Update: Try to fix formatting with opening *and* closing p tags. Content has not changed.

[mjeaton]

Nothing my contract explicitly says that I should comment every single line of my code before I leave so they can bring any Jerko to take over the script? Can they?

I don't see the problem. You are on a contract assignment. They have requested well-documented code -- every line may seem overkill for us, but for them, well, it's their code and if they want every line commented, so be it. The code belongs to them unless, as others have mentioned, the contract says differently.

As for the client bringing someone else in to take over the code, that's their decision. That is the nature of contract work. There is nothing you can do except live with it and learn from this experience.

You also want to be careful about doing petty things like removing all the line-breaks (although it is quite humorous and I'd love to see the look on their faces), it will do nothing for you except label you as a trouble-maker. People talk and you'd probably be surprised to find out that a future client "knows someone" at the old client...

mike

[jepri]

As others have mentioned, you could be out on the street tomorrow, minus your code. That's definately the downside of contracting. But let me point out the upside to you. We'll start with what the management may be thinking:
• We rely heavily on this kid
• All contractors screw over their employers
• Let's kick him out the door and get someone in house to maintain the code

It's an old, old story and you're not playing your part because you don't yet know what your part is. What they are expecting you to do is (in the nicest possible way) hold them to ransom. Both sides can choose not to renew a contract, but they have the potential to loose business if you vanish.

Maybe just blatently march up to him and tell him that you would like be be on a longer contract. Say that you would like to work for the company. Say that you're leaving ASAP. Negotiate cleverly. Say that you aren't happy here anymore and you won't renew your contract at the end of the month (don't be bluffing). Make them aware that you won't be able to comment every line before your contract runs out. You can have any relationship with your employer that you can negotiate your way into.

Heck, ask them straight out why they want you to document every line. You don't have to worry about being fired because you know that you're going anyway.

When I was a contractor I never said sir. I did my professional best in the job, but it was always in the back of my mind that my official company title was 'temporary resource'. You should always be looking out for the next job, the best time to jump. This sounds horribly arrogant and yuppie-ish, but consider that after three years of contracting at Compaq, I had my contract cancelled with 0hrs and 0mins notice, along with most of the office (this was just before the HP merger).

____________________
Jeremy
I didn't believe in evil until I dated it.

[zentara]

If your boss gets real "nit-picky" about not paying you until every line is commented, why not fight back and remove all newlines so the whole script is on 1 line, and comment it.

[trs80]

It comes down to time left on the contract and can that time cover the time it takes you to comment every line of code?

Depending on the vagueness of the contract, yours' sounds pretty vague based on the revision history, you are a hired hand that is to do whatever they ask no matter how absurd you might think it is.

Bottom line is they paid (are paying) for a product that they can use in the future with no loyality to the original developer.

The business side of programming is so ugly.

[blackadder]

Thanks very much guys.

I really have learnt lot more with posting than I ever did with all my other posting.

Thanks for your help indeed….

I have to put this down to experience (or inexperience), and will be more careful with my contracts in the future. I have to admit I never read my contracts I just sign it, however this time I have learnt my lesson.

VIVA Le’ PerlMonks