Slashdot Mirror
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.
Go around the managers. Or find a new job
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.
Put in some backdoors, or a phone-home option to some off-premise server and see what happens when the brown stuff hits the whirly thing.
What's this rm-rf command??
Woops...
Sorry boss, for some reason the code's all gone. It might take a hefty pay raise or a nice licensing fee to get it back!
mwahahahaha
End of problem.
-- Karma whore? You betcha. --
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
"What software?"
These jobs are easy to come by. Tell them to look for new work. Their bosses are tossers. Tell your friends to quit after finding new employment.
Problem solved.
They should claim that it already released under the GPL. That should scare them off.
http://ablegray.com
I say they should give them the software on time, with some convenient "extra features." If you catch my drift. If the managers want to be assholes, recipcrocate.
Quit.
Then release the app as your own product.
--
Don't like it? Respond with words, not karma.
If I develop or invent something during my spare time, it still belongs to the company. It depends on the agreement you signed when you began your employment.
geremy
"WRITTEN BY JOE & BOB, Warehouse #5"
Seriously... sit down with the boss and tell him your concerns. If he's a decent person he'll do something to alleviate them. If he's a shifty fuck then you need to realize that getting credit for software is not your largest problem.
Literalism isn't a form of humor, it's you being irritating.
if it works, all they have to do is stick their names on it and parley the sucess into positions as developers.
if it doesn't work, stick the managers name on it.
You mean jail time? I think that's what happens.
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.
work on the code;
make sure that it is known that the code is not meant for release, but is just an aid in their work;
include some serious backdoors into the code;
???????;
profit!;
Those who know, do not speak. Those who speak, do not know. ~Lao Tzu
What exactly is meant by spare time here? Is it downtime they have while on the job? Or is it developed at home on non-work time? This will greatly help determine whose code it is and what they can/can't do with it.
Keep in mind, however, that that's not all there is to it. Is the software currently deployed/hosted on company servers? Are they testing it at work or on work-related files/datasets/etc? Can be it be used for any company or is it designed so specifically that the average person would realize it was designed for the specific company? Even if they did this on their "own" time, if it uses enough company resources or is so closely tied to the company's business process, the company would have a very good chance at simply saying, "You volunteered this work but it's still out IP" and getting their way with it.
-- Fugacity: Confusing chemists since 1908
Seriously. Don't develop apps for work in your spare time. Just don't.
You may think of it as a fun side project, but your boss will invariably think of it as overtime. Nowadays, it doesn't make a damn bit of difference if you did it from home, either. Everyone brings work home with them all the time, so if you try to argue that it wasn't something you did for work because you did all the programming at home, your boss is either going to laugh at you because you've done plenty of work at home for him in the past, or, if he's clueful, he's going to laugh even harder because he knows that installing this software on the company servers is not something you can do from home.
Now I'm all for putting limits on what work can ask you to do on your personal time, so the boss shouldn't expect you to start working mandatory overtime to complete this app, but if he wants to shuffle some duties around and make development of this your primary responsibility, well, tough luck, but you were asking for it.
(I've been both, and currently am operating as both at the same time).
Assumption I am making:
1) There is a likely chance that you worked on this software durring office hours, after all, you developed it for this specific job. You are not a contractor, you are a full time employee. This makes it difficult for you claim it is yours because you developed it for your specific job. The only thing you really have going for you, is you are not a "developer". The assumption I will make here is that the company owns it, because if they see value in it, you'll get threatened with lawsuit if you claim you own it now. You probably signed a non-compete agreement anyways, saying you can't work on company related things at another company (OR YOUR OWN TIME). If its company related, they own it no matter what. Sorry.
You should expect recognition for your efforts outside your normal job. You could even get a promotion, into development, or maybe a bump up on the salary pole in customer service. As an engineer, I would actually expect something in return for this effort, if it turns out to be a large scale solution to a bigger problem. If you don't get anything, what the hell, you have a customer support job, quit and now go get a development job with this on your resume.
Your manager has a bigger objective, most "managers" have fallen into the trap already and are trying to climb the corporate ladder. He will be trying to get a big raise or promotion.
It makes more sense for a manager to get the raise/promotion, after all, he is responsible if everything goes WRONG not the engineer. Alot of people assume the opposite, if everything goes right, reward the engineers, but if everything goes wrong, the fire the manager. This isn't the case, and that is how its observed from above. Most "engineers" observe it "I get the reward if everything goes right, and my Manager is fired if I fuck up", that's NOT the case. Sorry.
Your case is fuzzy, because the Manager wasn't originally responsible for delivery of an alpha-product you've created, however may turn it into a real-project, with the VP's or company owners knowing now whats going on, they may now assume responsibility if it fails for lost time and resources. However, you have to look out for what really happends, it could be your managers keep it secret from the guys above until you finish the project, that way if it fails, they can just pretend like it never occured and no harm done. If it succeedes then they say they did this big thing for the company and pat you on the head.
Modesty is one of life's greatest attributes
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!
3. Lawsuit!
That's not a very likely option.
While it's difficult to start a business, market a product, etc., etc., they might be able to handle that. My bigger concern is that their product is probably way too specialized to be marketable. These sorts of applications are usually one-shot deals, designed to fit into a certain workflow that only exists at their company.
So what they ought to realize is that there is probably only one customer for their application. You could suggest having them demo the product, quit, and then offer to return on a contractual basis to finish it. It's still very risky, but I think it has a better chance of success than your original proposal.
You want the truthiness? You can't handle the truthiness!
I agree with the previous poster that MFC and HTML are not particularly related. Either the submitter made a mistake in naming his technologies or a troll question got posted or something.
However, let's assume that the story is true. Let's make another assumption that the problem the submitter's friends is not that management is taking what the developers feel to be their IP, but that management is trying to release something cross-company that isn't remotely ready for prime time.
This seems to go against the general trend of suggested lies and deceit that I've seen in the comments on this article so far, but here's what I would suggest:
Just be open with the business people - explain what you see as the consequences of them releasing this software with the current schedule, but stick to the facts and stay away from emotional or personal characterizations, like thinking about people as PHB's. Explain that the software is not documented or tested, and if they release unfinished software, it will probably be unreliable. Explain that the more critical the software is to the business, the more rigorously it has to be tested and documented. Explain that if they want to put this into production, they should have an experienced developer and/or project manager work out what needs to be done to get the software finished, and product a project plan, documentation, and most importantly, a test plan.
But also explain that you understand there are business considerations external to the technical side and that you feel your role is to explain to non-technical people the technical impact of their options.
That's what I would do.
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.
"If you'd like to change my job description, let's call HR and negotiate compensation." (And, perhaps, a better manager.)
They can't fire you for cause for not doing something that you were never expected to do.
Many arguments have been made regarding the fact that we don't know much about the circumstances of these individuals and what kind of contracts they may have, when they've been working on it, etc. However, there are some things we can probably ascertain.
We do know that they are customer-service reps. Which means two very likely things. First, they were not hired for their programming skills, which means they are likely not being adequately compensated for this software. Second, they are probably not under a non-compete clause of any kind. While programmers and high-level managers are often put under such things (which in my experience don't hold up very well unless they are extremely explicit), customer service reps are RARELY if EVER put under such restrictions. Why? Because the industry knowledge is pretty well standard for most of those things, they rarely have access to real trade-secrets, and most of their skills involvin simply talking and entering data - mundane everyday stuff.
The problem is that somehow they worked on software in their own time, at the company or not, and their bosses are going to try to make a credit claim. If they want credit at the company, they need to start writing documentation, documenting out the development process, the origin of the idea, and so on. Get those documents out to the right people and let them look over them. Put down where the project stands, how many hours of work they estimate they need to get to a completed project, and what a reasonable compensation level would be.
Lastly, they should sign their code, so that when some stupid boss claims credit for it, they can point to the code itself.
The big question would be whether the whole organisation is made up of jerks, or just their immediate bosses who might try to claim credit for it. If they don't think there is any fair management there, they should just stop working on the code, or write some psuedo-modules that make no sense and if implemented by someone who can't write code proeprly would eat the system, or else mess up the logic of the app for the uninitiated. Then they should quit and get better jobs.
Linux - because it doesn't leave that Steve Ballmer aftertaste.
Stop what your doing right now and think...
Were you coding this stuff *really* in your spare time??? Did you do this at home or while in transit back and forth??? Then the company might litigate you over the rights to the code under the "inventions" clause in most employee manuals. Or did you do it on company computers and maybe over *your* lunch hour? Then they have the legal right to take it from you since you were doing it on their hardware.
It might be time to hand them what you've done and say; "Its now your problem. I was not hired here as, nor does my job description call me a !developer!. However you are now beginning to treat me like one. Does this entail a substantial increase in the monatary renumerations that I (we) see on the paycheck at the end of the pay period?".
Odds are, that's exactly what will happen. You will give up what you spent time on because the company will claim it as "inventions" and because you are an employee you are required to surrender this over to the company. This process is *assumed* when you took your employ with them in the first place. I had this happen to me once before and I learned my lesson way back when!!
Fact is that you should not have been engaging in this unless there was some "up front" possibility that they would encourage this and thustly reward this effort, or turn it into something better not only for the company, but where you also would benefit. From my personal history, managers are usually looking to retain their employ just as much as you are, and there is an old addage that goes something like;
"Sh*t rolls downhill, and your under me." (or some such to that)
Cheers;
Jeff
All content in this message is copyright (c) 2008. All rights reserved. RIAA is prohibited here.
Alternately they could f--- their bosses and release pornware ;-) and say their bosses made them do it :-O
Only 'flamers' flame!
Does slashdot hate my posts?
1. Quit, sell back the code, get lucrative support consulting fees.
or
2. Do what the boss says, finish development, release, watch boss get credit.
The probabilities are very high that the 'spare time' that is referred to actually was on company premises and equipment, and that work usually belongs to the company as per the employment contract. So #2 is the most likely to happen. Trying to pull a #1 will probably get you sued.
Now, to mitigate #2, Attain high visibility, get involved. The best thing to do: prepare a really snappy Powerpoint presentation and (this is the important part) present it yourself. Do NOT let the PHB do it for you. Insist on being there an any or all meetings about the project.
While you're at it, sprinkle your name/initials on every possible comment line, and document produced. Make it close to impossible to whitewash your existence out of the project.
Finally, what the PHB wants is recognition. Praise him publicly for allowing you to develop this very useful project. You did the work, PHB enabled you to do the work. Win-win.
You send Tron to the MCP to deliver a virus. Just watch out for the gridbugs ...
Drag their feet, show some badly done code and claim they're just goofing around trying to figure out stuff.
Then go home and write it in generic terms, copyright it, and make it available on their own terms to whoever they wish. That wish may be measured by monetary offers should they so choose. Anyone making such a monetary offer does not need to know how many or few others are making such an offer (or if others even exist), what those offers might be, whether the authors will settle for a lower offer from a prefered customer, or whether they'll accept multiple offers despite the fact they differ.
"I may be synthetic, but I'm not stupid." -- Bishop 341-B
There's only one way to deal with this.
GO POSTAL!!!
In the "About..." help dialog, have the developers put "Devised and developed by {insert names}" to ensure that the foolishness of their bosses' attempts at running away with the credit is forever emblazoned on every machine in the entire company that uses the software.
If the manager appropriates your software for his own uses, and locks out all Group 7 access users so you can't prove it, you should come back, late at night, with a forged Group 6 access code, and taunt the company mainframe until it's forced to challenge you to a battle on its own terms.
Then after defeating it, you should get a printout proving the software was originally yours.
o/~ Join us now and share the software
The software would have had to been on a company computer at some point in time, or they wouldn't have been able to do any sort of testing. If they were somehow able to claim ownership and try to license to the company, the company could fire them for serveral things, such as uanathorized use of company equipment, installing potentially dangerous software, uanathorized access of confidentail company data and probably a laundry list. They'd be unably to market their software and out of a job. The company will simply have to backfill two less technical positions.
Someone hates these cans.
get a real developer job. this is the kind of question that highschoolers ask....
Just find a new job. Very politely give your two weeks notice, don't mention the project in any form.
Delete the source code. If questioned just say, you didn't like the direction of the code and deleted it. Since you are leaving, you will not be working on the project anymore.
Its just a program. Big freakin deal. Any developer with any kind of experience has thousands of lines of their own code that they no longer use. No developer keeps around code written early in their career. Its just too damn embarassing to look at.
Forget the project, forget the boss. Get another job.
Lets be honest, the first program written by customer service reps with no experience building large scalable apps isn't likely to be all that great. Suck it up as a learning experience and move on.
If they want to be developers they better get used to throwing away code.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
If the bosses are really that clueless, make it a wiki of all the stupid things those bosses have done and said over the years and "go national" with it.
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
I think it is likely that the developers are hoping to increase their importance to the company and hopefully be compensated for this either monetarily or with increased job security. It appears these aspirations may be in jepoardy if their supervisors take the credit. So it's possible this application might be legally considered company property, but who says it has to be fully functional past a specific time frame if certain conditions are not met? Or what if all the most valuable functions are only available in the "full" version? These guys may become skilled developers, but they need to develop their negotiating skills if they hope to get anywhere.
Submit and download your homegrown music on www.audiodropout.com
"Make your bosses look good, and they can help you get promoted to squire. That's no great shakes either, but at least it's on the way to becoming a knight."
Pfft! Screw that. I want to be prince charming.
"They had an experimenter describe another person to a subject. The subject was later asked to describe the experimenter and many of the attributes of the person being described were attributed by the subject to the experimenter. It turns out the human mind has a "birds of a feather" wired in: losers associate with losers, slimeballs with slimeballs."
I'm with the poster! Like Laurel and Hardy, Abbott and Costello, Ginger Rodgers and Fred Astaire, Lucy and Dezi, pull-tabs and pop-tops.
If they truly did develop this on their own time, using the companies computers they are guilty of improper use of company equipment. If they did it on company time, then they are also guilty of getting paid for not doing thier job. Either way, the company owns the code. If they did this on their own computers, then they own the code and the company has the right to can them for installing and running unauthorized software. Anyone see any possible angle where the company doesn't have a good reason to can them?
I figure their quick-n-dirty solution was some little widget that let them lookup or compile data quicker than using the provided software. Probably a time-saver, too. Whether their software is scaleable is doubtful. Could also be a security issue, because we all know that quick-n-dirty is rarely high quality coding.
Since employees use the tools provided by their employers, &
...could these guys argue (in an IR could) that:
:-)
contractors use tools that they provide for themselves,
- they are really contractors
- they own rights to their code
- get court to agree
- PROFIT
Make sure to embed the Easter Egg that gives you extra credit for having written it. Then if they steal it, you could prove that you own it (at just the right moment, in front of official witnesses and lawyers) and they didn't pay for it.
So, what if some future underlings want to follow the other posters' plan,
ie, use a successful software project to position themselves
for a job-change (into dev't) & salary increase?
Screwing the boss who saw promise in their efforts won't
help them achieve their goals.
FACTS: a) They don't know what it does in the first place. b) They don't know what it looks like. SOLUTION: Deliver a pos tool that doesn't actually do anything of value, or anything at all. It would take all of 5 minutes to code, and solve all of your problems.
Sounds like an excellent time to give them a good fahrenheit to kilometres conversion program. Then run.
One line blog. I hear that they're called Twitters now.
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.
Everything on my side of the project that I work on, tools and tech-wise, is made and released just to be barely functional. They work, but they don't work well. Nonintuitive interfaces, obvious lack of features, ec. I cannot count how many times I have used something for a task required to my job and thought hey this would take 75% less time/effort if it only read input from a text file or some other very obvious improvement. There are people with my identical job tasks across the country/world dealing with this and sometime last year I took it upon myself to develop a very small app that basically replaces a web-driven tool of questionable quality that was supposed to do the same things. My intentions were to mainly make my job easier; I saw no reason why it should take me 1 - 2 hours to do something when in a weekend i could come up with a basic app that did those same tasks in 1 - 2 minutes (real figures) Result: I get to work 8 hour days instead of 9 or 10 hour days. Hey, good enough for me. I do the same thing in smaller doses too with scripting, etc. I'll admit there was a bit of me trying to prove a point and a general f-you to say 'it shouldn't be this hard, see?'.
Anyways, what the app I made does is mostly so proprietary that it couldn't be released/sold publicly without majorly overhauling it and turning it into something completely different. I did end up turning it over to the tools team, after I refined it for a year and made it as bug-free as I could. I did enjoy turning over a large amount of C++ to a team primarily focuses on VB/script-driven tools. It still makes me laugh.
I've read most of the +5 comments here, and everyone is overcomplicating this issue, save a few of you. I have seen this happen in my own company and heard about it happening in friend's companies as well, particularly in the "customer service" or "tech support" call center departments. What happens is that the world around us changes and changes and changes, and the paid developers don't have the time or need to develop "mini-apps" to make certain work-arounds easier for the customer service people that talk to actual, real, live, external customers all day to make a living. So one or a few different enterprising individuals hack together a web page of contact info, or a really simple PHP website that can auto-generate a particular type of e-mail response to the most frequent customer complaints, or throw together an Access database with a bit of behind the scenes code to track evolving issues more accurately. I know this happens because I have done it myself, on more than one occassion in more than one job role at my current company. It's just a fact of being a worker in the trenches of a large company.
So, how does this answer the question posed by this "Ask Slashdot"? Well, the answer is that because these two friends are the workers-in-the-trenches types, they're NOT going to be able to steer their manager clear of releasing a half-baked software package or app or webpage or whatever it is to the entire company's "customer service" departments. What they CAN do, as only a few other people have mentioned, is take credit for it on their resume. This isn't cheating, it's not lying, it's just good business sense. Don't be mad at me or the few other Slashdotter's who suggest this approach. We're not being weasly, and it's not wasted effort. Finish the app (hopefully in the time established by the manager - who obviously needs to now look good since he/she jumped the gun and told all their peers what "their people" were gonna do by a certain date), claim the success of deploying it nationwide when you hadn't even expected it to do anything more than help yourself, and then start sending your resume out for those entry-level programmer/analyst job positions. No, they're not being paid NOW for this work, but this WILL show initiative, drive to get a project done on a timeline, and the ability to "think outside the box" in a job, and to another employer this is the kind of person they'd want working with and for them. They don't want the jaded and cynical type of person on their team. They want the person who is enthusiastic about their work, but also smart enough to realize when they've exceeded their job requirements enough to go looking for a new job.
Tell your friends to remain upbeat, claim this as a major victory on their part, and then find a new and better job. Yes, their current manager sounds like quite the asshat, but that's no reason to retaliate in kind.
Had this happen twice. Hired to technical, but nondevelopment, jobs. Developed a VB product recall app at one place, a ASP frontend and a SQL database for best practice tracking at the other. When I moved on, I explained that since I hadn't signed anything like a work product agreement automatically assigning IP rights to the employer, the code was mine and would be going with me unless they wanted to buy it, train someone, and assume full support (I wasn't interested in being a support vendor for either company). One paid, one didn't. Neither challenged that it was in fact my property.
I don't doubt that if their bosses wanted to be pricks they'll wave lawyers at them, claiming that they own the SW, that they can be fired for misuse of company equipment, yadayadayada... Simple fact is, as long as the application is mildly complicated, and has some value, these guys hold the cards. Even if it's determined that the company owns the software, apparently all the own right this second is some non-tested, yet to be debugged code chunks, and not a whole lot a court an do to compell these guys to actually finish the software. They can be fired, but the company doesn't get the software. They can be harassed, company doesn't get the software. Company can hire folks to reverse engineer and finish what's there, and company gets the software - for a significantly higher price. Company accomodates them, they get their software. If they're that worried, call a lawyer and preempt the weasel managers.