Solutions for When Managers Hijack Your Code?
Chiggy_Von_Richtoffe asks: "Two friends of mine work at a warehouse distribution center. First, they are customer service representatives, not paid developers. Secondly, the are developing the software in their spare time to make their jobs easier using MFC and HTML. Their bosses have already talked up the idea behind their backs, and then came back to them with a deadline to release the (in-house) software, on a national level. However, they haven't had time to release their first version, and the bosses don't even know what the software can do nor even what it looks like. There is a feeling that the bosses may pat them on the head and run with the software for their own promotions. What should they do?"
I'm not even able to figure out what question is being asked here.
It sounds to me like they've created something, probably wanted to show the bosses to get some love pats (btw, DON'T DO THAT! HAVE YOU NOT BEEN READING RECENT /. ARTICLES?). And now, they're upset because the bosses want to run with the
stuff. That's kind of what happens. Sounds like the "service reps" were a little
naive, and the bosses were greedy and stupid.
(Aside: I used to work in IT, and if service rep people wanted to roll their own, there was little to be done to stop them. But PHB's who were gushing over these home grown "apps" that were successful talking the rest of the company to adopt and deploy ALWAYS ended up costing the company tons of money.... the apps were never scalable, maintainable, compatible with anything else. I'll allow that it's possible but I've seen this kind of scenario many times, and they've NEVER brought positive ROI.
If they're doing it on their own time then they have control over it. They should license it to the company.
(Sponsored by cheeseSource for President 2012)
Lemee see.. People are taking your projects behind your back.
... What in the hell do you think?? RUN, and RUN QUICKLY.
Those people havent tested it upon anybody.
Those people probably havent debugged it well.
Those people arent qualified (Customer service reps).
The managers are supporting them.
1. Make grandiose promises to inept managers regarding capabilities of software
2. Play Xbox until deadline for "RTM" arrives
3. Deny and involvement with manager's pet project.
4. Laugh uproariously as former managers are escorted off the premises by security for their complete and utter failure to meet deadline
Personally, I would do my best to make them look as stupid and inept as possible. You might just be doing other underlings a favor in the long run. They'll be much less likely to use subordinates in the future.
End of Line.
If it is done on their own time and dime, then they should register a copyright and use it to bargin a payraise/promotion.
If they are doing it on company time, then it probably belongs to the company, and they are probably screwed.
If they developed it on their own time (and preferably at home, not using company computers), then it's their IP. It's not part of their job description, and it's very unlikely they're getting paid enough to be developing software on a work-for-hire basis. So...
What they should do is draw up a contract/proposal, detailing the features, testing proceedure, launch proceedure, and compensation. If they don't actually want to do it, just put a huge price-tag in there. Of course, any price tag will probably make the manager balk as he/she probably thinks they're getting this new system/utility for the $9/hr they're already paying these guys.
DONT PANIC
If I developed it on my "own time"- when I wasn't at work- then I would tell the managers that it's my software, and would be happy to liscense it to them, once I'm finished with it and have opportunity to test it. If I developed it "on company time when I was bored anyway"- then I would tell the managers that quality software takes time to develop, and if the deadline is unreasonable, warn them you won't be able to make it. If the manager(s) try to steal the credit, intelligent people will still realize that the managers didn't write the program. Also, if it's good enough to go to the national level, then the managers deserve some credit for recognizing that anyway. What sort of idiots the managers are will affect what will work and what doesn't. Your friends will know beter than me.
You are reading a copy of my copyrighted post.
Wow...this sounds like so much bullsh*t.
1. MFC and HTML? WTF? What does that even mean? How are MFC and HTML integrated at all?
2. "In their spare time?" What does that mean? Their "spare" time at work? Too bad. If you worked on something on your company's time, it is theirs. If you worked on it on your own time, it is yours.
3. Their managers don't know what the software can do but they're "talking it up" and releasing it across the country? Yeah....that's likely.
4. How can managers "hijack" your code? You work for them. Anything you do in their supervision is their responsibility. How is that hijacking? They may "run with it" for their own promotions? WTF!!!???? Instead of what? Promoting these guys to vice-presidents? Get real. Do you really think these guys should be revered as gods throughout the company, for writing this? All you will ever get, even as a developer, is a salary, and perhaps, if you're lucky, a "good job". You will NOT be promoted for coding anything.
Man, I am so tired of these whiny questions..."My boss blah blah blah". It's a job. Grow up, and figure it out.
Ahem: "They used MFC? Then they deserve any abuse they get."
I'm sorry, I just couldn't resist. Now, on to the thingy.
First, I'm going to work under the assumption that "on their own time" actually means "during down time when the reps were sitting in front of their computers but not actually taking calls." If that is the case, it will be hard for them to claim copyright on the application, because it was done on the employer's time and using the employer's resources. That just strikes me as the most likely interpretation.
Now, it's not fair for their bosses to be expecting them to do software developer work at phone jockey prices. When they set a deadline, this thing stopped being "a fun way to spend down time" and became part of their job duties, additional duties which require skills that most of their peers don't have, and for which they aren't being compensated. That isn't acceptable, and hopefully they'll be willing to stand up for themselves.
My suggestion: They should go back to these bosses, explain that their work up to this point has gone far above and beyond their actual job duties, and that if the bosses expect that work to continue then the coders should be rewarded above and beyond their actual paychecks. It's up to them whether they want this compensation in the form of money, a transfer to full time development work, prestige, scooby snacks, or glib promises that the bosses don't intend to keep.
If they can strike a deal, great. Tell them to get it all in writing, then build the software according to the highest standards of which they are capable.
But if negotiations fall apart, and the bosses come back with a "do it or you're fired" ultimatum, they're still in control. If they want, they can build InHouseApp 1.0, Teh Suck Edition. Random crashes, database corruption, an awkward, unintuitive interface... whatever it takes to embarrass the bosses who made such wild promises. Just remember that it has to be so sucky that the old way is far preferable, so they don't have to eat their own dog food.
Or they can build it nicely anyhow, and hope that their work will gain them some recognition. I wouldn't suggest this option, though. There is no reason for them to make it easy for the bosses to take advantage of them. For the same reason, they shouldn't even consider trying to take ownership of the application. Don't give them an excuse to file a lawsuit. That means letting management have the current codebase, rather than stripping out all the comments and adding a few judicious memory leaks.
Finally, in case of termination or threats thereof, make sure they know how to reach their bosses' bosses. They should have someone they can go to to explain their side of the situation.
You want the truthiness? You can't handle the truthiness!
Lets assume that they did it at work and are now given a deadline.
I say go for it.
Let your boss know that you need to dedicate more time to the project and cannot meet the deadline with the interuptions of your current job.
At 3/4 of the way finished send an email to your boss and copy HR on it asking to be reclassified with a different job title because the duties of your job have changed so much. (some companies call this a pay raise)
Never say it is done. We all know that revisions will need to be made and bugs to be fixed. Give it a long beta phase. I bet you will get lots of visibility because of the project. Once it goes to the support phase, you boss will still be clueless and you will be called for everything relating to it.
Now you have a internal project that the whole company depends on and goes to you for support. It makes your boss look good and gives you a great refference. You get exposure to the develoment process and customer side of programming.
Its a great resume builder and I am guessing this is just a temp job anyway. So once it feels stable, find another job. Then you can make more money when they contract you to fix, upgrade, redesign, or want to scale it.
Besides, if they are developers at heart, they would prefer to do the project than their real jobs.
Im a gamer, not a grammer major. This post is full of spelling and grammer mistakes.
The company I work for currently has a home-grown solution/program in place. I use the program, and have found numerous bugs.
I fix show-stopping bugs (since I rely on the program, and major bugs make my job more difficult) as they come up.
I *really* want to do some more work on the program. Clean up the code (it is in PHP), comment it a bit, and fix some of the hacks that allow it to work to more permenant solutions.
I am not a developer for the company, though, and do not get paid to do development work. As such, as tempting as it is, I only touch the code if a new release completely breaks things. [Yes, I think it is possible the sole developer, who I think got a small contract from the company teo develop it, is not a developer either, and probably does not QA on any release].
Some things I could do would make my job easier, but I have no desire to do something "out of the kindness of my heart" for the company without some form of payment.
Sometimes I feel greedy for my position, but I also reaslize that if I write a good enough program to make my job 10% easier or faster, the company would be more than likely to cut my hours 10%.
I suppose that is a comment on company loyalty (going in both directions)
- (c) 2018 Hank Zimmerman
Okay, there is some back and forth over who 'owns' the code. IMO, you don't want to get into a pissing contest this way - the company can likely hire more lawyers, and make life crappy, even if you are ultimately the victor.
Take the bosses aside, off-premises (lunch hour, after work) and have a candid conversation. They agree to a contract with you to code said software. Be nice and professional and all that, and don't threaten. If they refuse, tell them ok, they can have the thing as-is, but you won't work on it any more, since you don't want to be accused of using company resources for a personal project (which is what it is unless the company wants to pay for it). Then deliver the POS code listed in earlier post - the 'rigged demo' version. It should do something marginally useful, but as little as possible. If they gripe, tell them you hadn't gotten around to making it fully functional yet, as it was a 'personal project". This gives you plausible deniability. Playing stupid is one of the only defenses against a malevolent boss.
Oh, if they do refuse the contract, find their competitor and offer it to them. Since your current employer refused it, it should be fair game, and they can't sue you over something they can't even identify.