In the last few weeks what ,could be my argument for NOT doing a handover........

[speling bee]

Well, there was a thread on here many years ago where the poster asked the same question. His argument that he was not there to train people how to do a job and to help THEM understand code that he had not written. I remember something along the lines of him making parallels to him being a doctor, he would analyse the symptoms, give a diagnosis but not tell the patient HOW he came to the conclusion of his understanding of the illness.

I received no help in understanding the code, maintaining the code and running the code, nor should the Bobs.

Is the handover a defined deliverable in your statement of work?

[minestrone]

Just tell them to look at various bits of code you have picked at random.

That would be my handover.

[SueEllen]

Most documentation is never read.

Write a long and very boring document detailing everything but the code. Then put one paragraph in stating the code is self-explanatory.

Then send them the documentation just before you leave.

Even if you do make the document readable the Bobs aren't likely to understand it so you may as well have fun writing it to be as convoluted and useless as possible.

[vetran]

Document your improvements extensively and professionally to a high technical level (too high for the bobs), Draw a few basic flowcharts of the overall (be very careful which fonts you pick and pictures, make sure it looks perfect). Also make sure your support statistics are good and well documented, if there are any outages you want them to look back and see how quickly you fixed it originally and use it as a yardstick for the Bobs.

Remember Bobs will be experts at BS ing, however well you do the handover the only thing that will survive you is the documentation you pass to the client, make it look GOOD.

The Bobs will be tulip stirring before the door closes behind you. Make sure the bosses (not your direct manager that screwed you) can understand the basics easily using the presentations and rudimentary flow charts. 'Hey Mike(the bigger boss or a skilled senior tech with influence you like) can you run your eyes over this, I'm trying to make sure its the right level for the handover' - smell the teamwork!

Leave the handover to the last day if possible , until then show them the source control system and a few other simple things, then flash the flow charts quickly.

Spend lots of time training the Bobs that don't get it, they will have one bright one and loads of foot soldiers. Avoid the bright one asking any questions or getting a complete understanding he/she is the only one who will remember.

Of course toward the end of the handover let your concerns about the skill level of your replacements drift into conversation with the permies (you will be winding down, so become matey with people you can respect - if you are normal you are already doing / done this) along with your business card just in case they have any other good projects going.

Then stand a round in the pub / getting cakes , get the Bobs involved if you can to show there are no hard feelings and you tried your best.

If the Bob's screw up, then the permies will come to the rescue on some simple jobs, they will remember your skill, are unlikely to want the outsourcing to succeed, will want to get the work off their plate and might suggest you come back occasionally on a nice day rate.

You want to look like the good guy, its a small world you might be working for one of the permies at another client.

Outsourced Bob's however are unlikely to offer any decent contracts or care about you getting work so are fair game.

[sbakoola]

Is the handover a defined deliverable in your statement of work?

not yet.

[escapeUK]

Even if you do make the document readable the Bobs aren't likely to understand it so you may as well have fun writing it to be as convoluted and useless as possible.

This is what I would do. Though what veteran said was pretty good too.

Being professional is boring, napalming bridges is immensely satisfying. Though a tactical nuke like veteran suggests can be fun too.

[BlasterBates]

What´s the point. So you refuse to do a handover, then your code gets outsourced and they spend a bit longer doing what you did, and charge the client more money and the manager will refuse to sign your timesheet because you refused to do what they asked.

So the client loses money you lose money and the outsourcer earns more.

I just fail to see the point of this. Is it worth a few grand to get your own back?

[doodab]

Start by giving them what you were given. When they start to complain, point out that's what you were given.

Detail your enhancements thorougly so they can see what good docs look like and yo bumhole is covered.

Negotiate 2 weeks working from home at a higher rate to produce more docco and outsource it to some CS students. The resulting uml overdose should be indistinguishable from the real thing and impossible to check for errors. You may want to run it through a spelling checker though, students these days aren't what they used to be.

[VirtualMonkey]

Document your improvements extensively and professionally to a high technical level (too high for the bobs), Draw a few basic flowcharts of the overall (be very careful which fonts you pick and pictures, make sure it looks perfect). Also make sure your support statistics are good and well documented, if there are any outages you want them to look back and see how quickly you fixed it originally and use it as a yardstick for the Bobs.

Remember Bobs will be experts at BS ing, however well you do the handover the only thing that will survive you is the documentation you pass to the client, make it look GOOD.

The Bobs will be tulip stirring before the door closes behind you. Make sure the bosses (not your direct manager that screwed you) can understand the basics easily using the presentations and rudimentary flow charts. 'Hey Mike(the bigger boss or a skilled senior tech with influence you like) can you run your eyes over this, I'm trying to make sure its the right level for the handover' - smell the teamwork!

Leave the handover to the last day if possible , until then show them the source control system and a few other simple things, then flash the flow charts quickly.

Spend lots of time training the Bobs that don't get it, they will have one bright one and loads of foot soldiers. Avoid the bright one asking any questions or getting a complete understanding he/she is the only one who will remember.

Of course toward the end of the handover let your concerns about the skill level of your replacements drift into conversation with the permies (you will be winding down, so become matey with people you can respect - if you are normal you are already doing / done this) along with your business card just in case they have any other good projects going.

Then stand a round in the pub / getting cakes , get the Bobs involved if you can to show there are no hard feelings and you tried your best.

If the Bob's screw up, then the permies will come to the rescue on some simple jobs, they will remember your skill, are unlikely to want the outsourcing to succeed, will want to get the work off their plate and might suggest you come back occasionally on a nice day rate.

You want to look like the good guy, its a small world you might be working for one of the permies at another client.

Outsourced Bob's however are unlikely to offer any decent contracts or care about you getting work so are fair game.

Exactly this.
Don't be a fool and act like you are planning to. You're a contractor! We take the sh** no one else wants every day we turn up and this is hardly the worst thing you'll ever have to do. Turn up, follow vetran's advice and move onto the next one (after invoicing of course). Your self respect will be better for it.

[Platypus]

Good advice

That's very good advice IMO