How to benefit from being able to save my company from a disaster while being laid off cruelly [closed]

Question

I'm seeking advice on how to handle a high risk opportunity.

My employer recently had to do some layoffs due to changing the underlying technologies used for its products (ie: moving from C to C++, migrating from CVS to GIT, etc). For some stupid reason, they insisted that most of the developers would only be given 3 months notice, but they'd actually have to work it rather than being given 3 months' payout. One of the senior guys that was laid off got a nice 5 month payout, while the rest of us have to work at a job we now hate, and some of my co-workers actually have to train underpaid replacements.

So, everyone is being less than accomodating, griping over verbal language barriers, etc. I am in a very unique situation though. I'm working for about 6 more weeks before I have to turn in my keycard, and have been looking for new work. Due to shoddy IT policies, all the devs have access to the same master password for our data and versioning servers. One IT person (not me, fortunately) decided to do something very mean: he migrated the CVS repo with all our code to GIT, but just the HEAD revision, and there are no copies to be found of the server data from the old CVS server.

The code builds fine with the new GIT server, so we thought everything was fine. Wrong! We checked out the latest copy of a key piece of code (40,000 lines) that our products depend on. Someone (we can't determine whom, since it seems DHCP lease logs and SSH "last" logs don't go far enough back, "admin" user account used to do this), and someone ran it through a parser that:

• Removed ALL comments (these are key, since we have massive lookup tables of register values and bitfields).
• Removed all indentation.
• Swapped all integer literals so they are decimal rather than hex, so the bitfield values aren't apparent.
• Renamed all functions to useless, non-descriptive names.

An example would be:

Old Code

#include <iostream.h>

main()
{
    initDevice();
    int i = 0x8001; // Set MSB and LSB to enable diagnostic mode on older models.
    cout << "Hello World!";
    shutdownDevice();

    return 0;
}

New Code

#include <iostream.h>
main()
{
foo_0001();
int i = 32769;
cout << "Hello World!";
foo_0082();
return 0;
}

Remember, this was done against about 40,000 lines of code in hundreds of files.

Nobody noticed this because the automated build jobs just kept running fine. Now that things need to be changed, we're pretty much up the creek without a paddle. Me and a few of the other devs know a lot of this code, having written it, but it would be a massive undertaking to correct this mess so that it's at least usable to the point where we can make improvements, support new products with it, etc. Management is furious, and one of the software managers literally threw stuff around his office in a shouting rage when they found out no backups can be found. They have time-based backups, but it seems this change went in several weeks ago, so the oldest backup is this junk code too.

About a half year ago, I was doing remote work from home. The company encourages us to put in extra time via VPN, but it doesn't count as "working time". It's basically a way to get extra work after 5pm out of us for free. There is no policy against using personal computing resources to do work. I have a copy of the pre-SNAFU code base.

The workplace environment isn't great, but pays a LOT more than what I'd make elsewhere. When I'm let go in 6 weeks, it's going to be a pain paying the mortgage and supporting my family, but we'll survive. Is there any way I can capitalize on this? I've though out the following scenarios, and need advice on which route to take. Keep in mind I'm being 100% honest when I state that I was NOT the person who sabotaged the code base:

• Tell the owners I have a spare copy of the code.
  • Maybe they let me keep my job, chances are they won't.
  • I can't really demand they draft a new job offer for me, since it reeks of blackmail/extortion, and they could probably take me to court. They may even think I engineered the sabotage itself.
  • Very high risk, minimal reward.
• Tell the owners I worked so diligently on the project, which I did, that I have most of it memorized, but it would probably take me 2 years to completely recreate.
  • Safest option I can think of.
  • I actually have about 70% of that stuff committed to head, or know how to fix most of this in about 6 months.
  • Helps me pay the bills for a while yet.
• Tell them the same as above, and that I can fix it, but we'd need to negotiate a better pay rate (3x current rate) as an external contractor.
  • Only problem compared to above is it might make them think I'm the saboteur. Not something I want them to think.
• Leave the situation alone, and part ways in 6 weeks.
  • Obviously safest choice.

I don't feel I have any duty to volunteer the code to the company free of charge. I'm not IT support, and I'm not responsible for them not know how to do backup testing. Also, I'm not happy having to help train people that will replace me and my friends. I want to benefit from this situation so I'm not digging into my savings to pay the mortgage while I job hunt, and I don't want to make the owners suspect I caused this and come after me with lawyers, burning up my savings even faster.

Are there any legal routes where I can prosper from this complete disaster?

Update

It turns out I was mistaken. I never had a copy of the code.

The shouting manager has been sacked, so at least some good came of this.

All of us on notice were called into a meeting room with the CTO and head of the legal team, and they laid out the whole story I just described, and in clear words, said "you little parasitic ****eating ****wads ... we know it was one of you", and demanded us all to sign a written agreement noting that we claimed we had no part in the whole thing, with a legalese-ish clause at the bottom granting them rights to check our personal e-mail to confirm this.

One of the senior developers told everyone not to sign a thing, as there was no way it could benefit us. Nobody signed a thing.

I will simply stay away from this and ride out the next 6 weeks with a smile on my face. Sorry for multiple accounts, trying to protect my privacy.

And no, Jake/Jacob isn't my real name.

Final Update

First, here's "hello world" encrypted with the password I've used on the past few throwaway e-mail accounts. Pipe it through openssl enc -d -a -aes-256-cbc with my account password for this account and the previous two ones for proof.

U2FsdGVkX1/Q0Xq+Ium6X5BxoZ7ZhhpLtz7ltU+/WrM=

Anyhow, today was insane. Some crazy person on the team found this post and shared it with the team. Of course, the interim software manager got to see it. Well, someone e-mailed management with a demand for payment via bitcoin. No idea if they actually have the code or not. For all we know, it's a troll taking things too far.

Thank you for the sound advice. Staying clear of this. I'm still amazed they haven't just paid off the devs and sent them packing, rather than forcing a group of spiteful devs to train their replacements.

And to address one of the comments: yes, it's a "salary dump". The C developers are fluent in C++ as well, along with CVS, SVN, git, mercurial, etc.

Yes, I thought I had a copy of the code, but I was mistaken. It was a separate project that wasn't altered, not that it matters. I've decided to quit today, and will just zero-wipe my personal HDD at home. Problem solved.

Answer 1

This is not a decision you want to spend a long time contemplating: the longer you take to act the more suspicious it will look when you eventually come forward.

I really see three options:

1. Honesty

In this situation you are - somewhat - putting yourself at this company's mercy, and also counting on their generosity, which may be ... silly.

You go to your boss and say:

Listen, I was working from home 8 months ago and have an older version of the program on my personal machine. Here's a USB with it, it's yours.

If this person is a decent human being he will thank you from the bottom of his/her heart, and will offer you a reward. You could potentially ask for one at this point.

I know you guys are letting us all go, but if you were to offer me a bonus for helping you out I wouldn't refuse it. Have a great day.

You keep your dignity, and you take the moral high ground.

2. Stay Safe

If you're dealing with vengeful, irrational, and nasty people, then just keep quiet. If you suspect that any attempt to help them would end in you being accused of plotting against them then you're better off simply leaving in 6 weeks and washing your hands of it all.

However, at that point the company probably goes bankrupt, and a lot of people end up losing their jobs. It's not really on you, but you could do something about it.

3. Anonymity

Put the code on a USB, and type up an anonymous note saying:

I had this code on a personal laptop due to working on it from home. I don't want to get involved in this situation in any way, so please accept it anonymously. It's a little older, but better than nothing. Good luck!

Then stick them both in an envelope and leave it on a manager's windshield, or in any place where it will be found, but not be traced back to you.

Conclusion

I honestly do not think that you can leverage the situation into forcing them to give you a job. If you choose to try and deceive them into letting you "rebuild" the code then sooner or later they will simply come to the conclusion that you sabotaged the project for this very purpose.

Best to do without that particular headache.

Answer 2

What's your duty? Give it to them - if they want it.

As a paid employee, you have a fiduciary duty to provide them with this code that belongs to them in the first place.

You should not even begin to consider other alternatives. It's theirs. They pay you. Give it to them.

If they ever find out you withheld it when you knew they wanted it, you could be in a lot of legal trouble. I am not a lawyer. It's probably worth some money to go over your situation with a lawyer to get legal advice.

Do they really want it?

If you were encouraged to work from home on your own hardware, they should have been polling you and others who may have done the same for if you have copies - if they valued those copies.

Perhaps the copies are too old. Perhaps they have known copies that are even more current that they don't talk about, but that they don't want to use.

Conclusion: Find out what they want.

There's probably some perverse political stuff going on here that you're not privy to. Be delicate. But find out what they want.

If they want it, give it to them. You'll be the hero. Talk to a lawyer. Good luck.

Addendum

You didn't mention it, but CVS isn't distributed version control, like git. Maybe they assumed you shouldn't have an entire copy of the repo. Definitely time to talk to a lawyer.

Postscript

It turns out I was mistaken. I never had a copy of the code.

I wonder why you thought you did. Perhaps you thought CVS worked like distributed systems which you might be familiar with. I am disappointed with your desire to leverage the firm's mismanagement by using something they would already own as a bargaining chip.

Answer 3

The company owns the code. Any attempts of selling them their own code will end in tears.

When you are laid off, all employment contracts that I've had required me to destroy any copies of code, or generally any company documents, that I might have in my possession. And that's what you need to do. If you have been given notice, so you know you are going to be laid of, you might as well start cleaning up what's in your possession right now.

You might watch how well they are doing in the future and get some enjoyment out of it.

PS After your update: So the CTO was making false accusations against almost all developers and insulting them all at the same time. Well, that is going to help. What an idiot. (Why do I say "what an idiot"? If the code was deleted, it doesn't help. But if someone else had a copy at home, as you thought you did, or if the perpetrator had kept a copy, which is not unlikely, there would have been a small chance to get the code back. With his stupid behaviour, he destroyed that possibility). Congratulations for having one senior developer who kept his cool and gave you the correct advise.

Answer 4

In all honesty, I'd say your best option is to leave it alone and leave.

They have acted in bad faith, but don't stoop to their level. It sounds like they are a sinking ship. Step back and let them drown

Make no mention of the code, EVER. If you produce it, they'll likely suspect that you were the original vandal and destroyed the code so you could blackmail them with a copy you kept.

Answer 5

For me, there would only be two options.

Do nothing about it and let them stew in their mess. (I'd be very unlikely to do this, but I guess if I was unhappy enough I might) In which case I'd delete their files from my machine.

Secondly, give them the copy of the code.

Everything else you're suggesting is immoral at best and probably illegal if you ever get found out because it's misrepresenting the truth.

If you tried to sell them their own code in whatever convoluted way you have in mind, it would probably be thought that you are the one who sabotaged things in the first place. You're saying you're 100% honest but the whole tone of your question hinges on a lack of ethics and personal honesty.

Answer 6

First of all the company is at fault

• No version control
  Well no saved version
• Let's migrate from C to C++
  OK migrate may be good architectural decision but
  • Hey make a copy
  • Keep a core of C people that know the code and can do C++
• Weak package
  2 month severance and you have to work does not make you an ally
  Make you come to work with logon privileges - that is just STUPID

What you have is valuable to the company and I don't think you have legal or moral obligation to turn it over. Certainly you cannot sell it of give it to another party.

I would not give the code to them based on weak severance. It is easily worth like 1 year severance to them but what if they come at you rather than pay? It is clearly a poorly run company - I would not count on rational decisions.

Answer 7

My advice would be to stay out of this and don't get involved in any way. It's highly unlikely that you'd be able to get any form of reward (extended job, bonus, etc.) if you hand over the files you have.

In addition to that, the managers who were responsible for keeping backups (or for the people whose job was to make backups) will most certainly look for a scapegoat to save themselves. If you show up with the files, you can easily be made into that scapegoat - you really have no way to prove that you didn't cause the sabotage if the network records are as skimpy as you say.

In your situation, I'd delete the files, work off the last 6 weeks and look for another job in the meantime. You cannot (and shouldn't even try) sell the code to someone else - that would be illegal and unethical.

One could argue that it's unethical to not to hand over the files. I agree with that statement but if you go the ethical route, there's nothing that will protect you from the company if one or more managers decide to blame you. The company will have the resources for a long legal battle that you may or may not win at the end. You'll surely lose a lot of money in the meantime, though, if this scenario becomes real.

Answer 8

Your original question How can I benefit from a company disaster? exposes you as dishonest with ulterior motives. It is unethical to prosper personally during a company disaster such as in this scenario.

Your update makes my point moot, but I will still post this anyway to make my point - that you should take the high road give the company the code that you thought you had (which now you know you did not).

As suggested by option number 1 in @AndreiRom answer and by option 2 in @Kilsi answer, you should be honest in this situation. Your company owns the code and until the last day at the time you walk out the door, you have a duty to act in the best interest of your employer.

Some of the other answers suggest that by giving them the code, you open yourself to liability. If the company were to come after you, this would be an irrational decision on their part. The company has an interest in surviving. The OP by providing the company with the original unmodified code, has done a huge favor for his employer. For the company to take legal action against the OP, they would only be harming themselves. Without the OP's help, the company would most likely fail sooner or later.

If I was the owner of the company, and someone sabotaged the code base , I would gracefully take any help I can in restoring business operations and would recognize by cooperating with the OP, I am ensuring my own survival.

Answer 9

The legal route is simple: you are still paid, and in those 6 weeks must act in the company interest. I don't need to tell you what that route is, do I?

Answer 10

My kudos to the developer who made those changes to the crucial 40,000 lines of source code.The managers and executives of your company deserve that and worse.

My advice to you - keep quiet about the good source code you have. Your bosses are definitely going to suspect that it was you who intentionally changed the code to benefit from the situation and put you in a lot of legal trouble. You are under no obligation to help your company; let the managers and executives broil in their own juices.

Erase irrecoverably any copies you have of the good source code from before these changes were done from your personal devices (devices that you own, not company's devices). Destroy any thumb drives and preferably even hard disks that you own where you saved the good source code. This is in case your bosses decide to go to court for any reason and have all the computers of all developers, including their petsonal computers, sub poenad and searched for evidence to find out who did this. If you do not wish to destroy hard drives that you own, at least delete the good source code using one of those file shredding applications that make multiple passes and overwrite a file with bit patterns to make them even more difficult to recover or detect they once existed.