Did the Company ask me to do something illegal?
November 13, 2007 7:19 PM Subscribe
Did the Company ask me to do something illegal? Either way, how can I say no?
I work for a large Company. The Company has a new software division which is attempting to create a certain type of software that they can then sell to us, the branches, and possibly outside businesses.
However, this new division writes shitty software and our branch revolted and was allowed (by the higher ups, since the shitty software division was taking so long even get the us) to go with a third party vendor for this much needed piece of software. It's a piece of software that any business in our industry needs. This third party vendor's software, while not perfect, is pretty good and has been around for several years, works well and allows us to many things we were previously incapable of doing.
This piece of software, lets call it DocuPub, from the third party vendor, is a type of software the Company's new division is attempting to create from scratch. They are not doing a good job of doing this, though they keep promising the higher ups that they can create this software and when they do, incredible, wonderful things will happen and they'll change the world. Management has mostly bought it, but there appear to be limits to management's patience as this software constantly misses deadlines for completion and is hated by the other properties that have been forced to use it.
Last week, while on vacation, I checked my work email and found I had gotten an email from a programmer at the Compnay's software division, cc'ed to his boss, asking me to describe how DocuPub works, it's workflow and could I describe the process and better yet, send along screen shots of the process. I am not a programmer, but do understand most of the concepts of how DocuPub works and have helped set it up for our branch.
It's obvious to me that the shitty software division is attempting to learn how to write a competitor to DocuPub by "borrowing" from DocuPub. This bothers me and sounds illegal. Is it? If not, how do I handle this request, as I do not wish to help the shitty software division steal ideas and concepts from a reputable business? What's the correct, corporate way of saying no, while not appearing to say no and appearing to help? Everyone at the corporate office knows I'm the most knowledgeable with DocuPub. I am prepared, if pushed, to flat out say no and point out that the shitty software division writes shitty software and they should be able to think of these things themselves.
I work for a large Company. The Company has a new software division which is attempting to create a certain type of software that they can then sell to us, the branches, and possibly outside businesses.
However, this new division writes shitty software and our branch revolted and was allowed (by the higher ups, since the shitty software division was taking so long even get the us) to go with a third party vendor for this much needed piece of software. It's a piece of software that any business in our industry needs. This third party vendor's software, while not perfect, is pretty good and has been around for several years, works well and allows us to many things we were previously incapable of doing.
This piece of software, lets call it DocuPub, from the third party vendor, is a type of software the Company's new division is attempting to create from scratch. They are not doing a good job of doing this, though they keep promising the higher ups that they can create this software and when they do, incredible, wonderful things will happen and they'll change the world. Management has mostly bought it, but there appear to be limits to management's patience as this software constantly misses deadlines for completion and is hated by the other properties that have been forced to use it.
Last week, while on vacation, I checked my work email and found I had gotten an email from a programmer at the Compnay's software division, cc'ed to his boss, asking me to describe how DocuPub works, it's workflow and could I describe the process and better yet, send along screen shots of the process. I am not a programmer, but do understand most of the concepts of how DocuPub works and have helped set it up for our branch.
It's obvious to me that the shitty software division is attempting to learn how to write a competitor to DocuPub by "borrowing" from DocuPub. This bothers me and sounds illegal. Is it? If not, how do I handle this request, as I do not wish to help the shitty software division steal ideas and concepts from a reputable business? What's the correct, corporate way of saying no, while not appearing to say no and appearing to help? Everyone at the corporate office knows I'm the most knowledgeable with DocuPub. I am prepared, if pushed, to flat out say no and point out that the shitty software division writes shitty software and they should be able to think of these things themselves.
It's not illegal to copy functionality. Software companies do it all the time. Look at the Zune and Ipod, for example, or at Microsoft office and Open Office.
If you had signed an NDA and had access to the source code, that would be completely different.
posted by chrisamiller at 7:25 PM on November 13, 2007
If you had signed an NDA and had access to the source code, that would be completely different.
posted by chrisamiller at 7:25 PM on November 13, 2007
From what you described, I see nothing illegal or even wrong with what they asked. If you would like an example, compare how similar Microsoft Office and OpenOffice are. They are not requesting any of the source code from DocuPub but rather the layout of it. What puzzles me is why they are asking for you to do this and take screenshots and such. I would approach this less from the ethical standpoint of thinking it's wrong and more the standpoint of it's not your job. Tell them to go buy the software and examine it themselves.
posted by chrisroberts at 7:26 PM on November 13, 2007
posted by chrisroberts at 7:26 PM on November 13, 2007
Why would that be illegal? You (as in your "Company") owns a license to DocuPub, which you work with. They're asking you for competitive analysis about how it works. Every company does it, for every single software product.
posted by cmonkey at 7:27 PM on November 13, 2007
posted by cmonkey at 7:27 PM on November 13, 2007
It is not illegal to reverse engineer software from the outside (buying a copy, using it and figuring out how it does things), and interviewing real-world users of said software is an accepted part of that process.
If your company really is going to replace DocuPub with its own "solution", then it's probably in your best interest to show the programmer(s) how the parts of DocuPub that are important to you work. The better insight you can give, the less likely their software is to be shitty.
posted by toxic at 7:28 PM on November 13, 2007 [1 favorite]
If your company really is going to replace DocuPub with its own "solution", then it's probably in your best interest to show the programmer(s) how the parts of DocuPub that are important to you work. The better insight you can give, the less likely their software is to be shitty.
posted by toxic at 7:28 PM on November 13, 2007 [1 favorite]
are they stealing code ? or just asking for your assessment on how the software works / looks ? i don't see anything illegal in it, and they are asking for your opinion so they can make the best possible product and you're familiar with it, and you're a loyal employee who values his job and wants to see his company succeed. no ?
posted by dawdle at 7:28 PM on November 13, 2007
posted by dawdle at 7:28 PM on November 13, 2007
You're their customer, and they want to know how you interact with this type of software, so they can better serve you.
It sounds they have some problems with their ability to make high quality code on time, but this is a totally reasonable request.
Your main concern at this point should be that this may be a waste of your time, and you have tasks that you would like to get done on time, rather than slipping your timeline so you can spend however many hours doing UI research for these guys.
At least let your boss know that this is using his resources.
posted by aubilenon at 7:35 PM on November 13, 2007
It sounds they have some problems with their ability to make high quality code on time, but this is a totally reasonable request.
Your main concern at this point should be that this may be a waste of your time, and you have tasks that you would like to get done on time, rather than slipping your timeline so you can spend however many hours doing UI research for these guys.
At least let your boss know that this is using his resources.
posted by aubilenon at 7:35 PM on November 13, 2007
It sounds perfectly legitimate and reasonable. What's wrong with trying to help the company build a better product?
But if you want to get out of it, it's unfortunate that you can't help because you are so impossibly busy doing your actual job. Maybe once this quarter is over, you'll have some spare time.
posted by Pants! at 7:35 PM on November 13, 2007
But if you want to get out of it, it's unfortunate that you can't help because you are so impossibly busy doing your actual job. Maybe once this quarter is over, you'll have some spare time.
posted by Pants! at 7:35 PM on November 13, 2007
Response by poster: Ok, it's not illegal. Got it. How do I get out of it? Refer them to the third party contact?
posted by MichaelKnight at 7:47 PM on November 13, 2007
posted by MichaelKnight at 7:47 PM on November 13, 2007
Talk to your boss, and tell him that it's too much of a drain on your time.
In the long run, though, giving your input now might result in software that saves you much more time later down the road. If they design the in-house software using naive assumptions about how you're going to use it, you might find yourself very frustrated later, when your boss mandates that you switch to the in-house solution.
posted by chrisamiller at 7:53 PM on November 13, 2007 [1 favorite]
In the long run, though, giving your input now might result in software that saves you much more time later down the road. If they design the in-house software using naive assumptions about how you're going to use it, you might find yourself very frustrated later, when your boss mandates that you switch to the in-house solution.
posted by chrisamiller at 7:53 PM on November 13, 2007 [1 favorite]
I'm a software developer.
I'm actually shocked that you think that might be illegal. It is certainly not, and a very normal thing to do.
posted by delmoi at 8:01 PM on November 13, 2007
I'm actually shocked that you think that might be illegal. It is certainly not, and a very normal thing to do.
posted by delmoi at 8:01 PM on November 13, 2007
Response by poster: There is backstory. Shitty software division has a history of assessing what each branch needs then ignoring those specs and doing whatever they hell they want hence one of the reasons we revolted. They have consistently dropped, fumbled and fucked up the ball, while of course blaming everyone else and I have no desire to help them, as they're the pro programmers, they should know how to write software as opposed to bullshitting with management.
We know we need. We gave them specs. They were outright ignored as shitty software division "doesn't have time to do all that, there are other branches they have to get to". I want no parts of helping them, in any way, shape or form.
posted by MichaelKnight at 8:09 PM on November 13, 2007
We know we need. We gave them specs. They were outright ignored as shitty software division "doesn't have time to do all that, there are other branches they have to get to". I want no parts of helping them, in any way, shape or form.
posted by MichaelKnight at 8:09 PM on November 13, 2007
Yeah, just tell your boss (or whomever you think can influence what this software division is working on) that you have no faith in their ability to actually produce software that works as well as DocuPub. Whatever the precise systemic problem that's preventing them from creating useful software, it's not more data they need. Tell him it's not worth your time to give them this data, and it's not worth the company's time to keep funding this project.
Do you, based on your position, have credibility when it comes to evaluating software engineering? If not, can you find someone who does to back you up?
posted by electric_counterpoint at 8:19 PM on November 13, 2007
Do you, based on your position, have credibility when it comes to evaluating software engineering? If not, can you find someone who does to back you up?
posted by electric_counterpoint at 8:19 PM on November 13, 2007
You could do 1 or more of these things:
- Delay. Tell them you'll get to it "soon", but are busy right now.
- Re-send the specs you originally sent, and explain that this is what you need, and DocuPub fills those needs.
- Send extremely vague, piecemeal information about DocuPub. Stretch the process out to make it agonizing for them. Of course it will be agonizing for you too. I hate trying to do substandard work for this kind of political reason.
- Tell them they are the software engineers, and would probably do a much better analysis of the program than you could.
- Tell them you don't work for them and can't help them.
posted by Artifice_Eternity at 8:21 PM on November 13, 2007
- Delay. Tell them you'll get to it "soon", but are busy right now.
- Re-send the specs you originally sent, and explain that this is what you need, and DocuPub fills those needs.
- Send extremely vague, piecemeal information about DocuPub. Stretch the process out to make it agonizing for them. Of course it will be agonizing for you too. I hate trying to do substandard work for this kind of political reason.
- Tell them they are the software engineers, and would probably do a much better analysis of the program than you could.
- Tell them you don't work for them and can't help them.
posted by Artifice_Eternity at 8:21 PM on November 13, 2007
This is not illegal and I don't consider it unethical. It's very common practice.
How do you think OpenOffice ended up such a close match for Microsoft Office? Or how Excel originally ended up so similar to Lotus 1-2-3?
It wouldn't even be unethical if the people in that other division bought their own copy of the program and spent a bunch of time using it. Very normal, completely acceptable.
In fact, not doing that would be stupid. It would be an example of NIH.
posted by Steven C. Den Beste at 8:33 PM on November 13, 2007
How do you think OpenOffice ended up such a close match for Microsoft Office? Or how Excel originally ended up so similar to Lotus 1-2-3?
It wouldn't even be unethical if the people in that other division bought their own copy of the program and spent a bunch of time using it. Very normal, completely acceptable.
In fact, not doing that would be stupid. It would be an example of NIH.
posted by Steven C. Den Beste at 8:33 PM on November 13, 2007
Response by poster: My boss, like me, wants to deal with them as little as possible. We could not have revolted without him, but we, and he, can only push things so far. We don't know how far.
I do have credibility with evaluating finished software, but that may not matter. Management has a history of being dazzled by bullshit as opposed to the rank and file who work with the tools. This part of the reason why I don't want to help, as I don't want to be part of a sinking ship.
Understand that I have zero faith in shitty software division's ability. They've put out steaming turds that made people's jobs harder. For instance, rather than being able to enter data into their software only once, users (other divisions, not us) have to copy and paste multiple fields of data from one part of the application to another. Rather than being able to take formatted text (like bold and italics) from a Word document, they tell to just copy and paste and reformat the text. These are multi page documents!
They can sink or swim on their own.
posted by MichaelKnight at 8:37 PM on November 13, 2007
I do have credibility with evaluating finished software, but that may not matter. Management has a history of being dazzled by bullshit as opposed to the rank and file who work with the tools. This part of the reason why I don't want to help, as I don't want to be part of a sinking ship.
Understand that I have zero faith in shitty software division's ability. They've put out steaming turds that made people's jobs harder. For instance, rather than being able to enter data into their software only once, users (other divisions, not us) have to copy and paste multiple fields of data from one part of the application to another. Rather than being able to take formatted text (like bold and italics) from a Word document, they tell to just copy and paste and reformat the text. These are multi page documents!
They can sink or swim on their own.
posted by MichaelKnight at 8:37 PM on November 13, 2007
Don't take your resentment over being used as an equivalent of illegal activity. You're angry at them because they're badly behaved (and fearful for their jobs), because what they do, frankly, sucks.
Just overfed them. Tell them all sorts of things you need to do (with #1 being able to import/export the third party software)...and then don't use theirs.
posted by filmgeek at 8:47 PM on November 13, 2007
Just overfed them. Tell them all sorts of things you need to do (with #1 being able to import/export the third party software)...and then don't use theirs.
posted by filmgeek at 8:47 PM on November 13, 2007
Best answer: If they're really that incompetent, e.g. your Word example above, then they're hardly capable of reverse-engineering DocuPub. Just do the minimum you need to do to give them what they want and let them fail, again.
posted by bingo at 8:52 PM on November 13, 2007
posted by bingo at 8:52 PM on November 13, 2007
I don't see why you don't give them what they're asking for. From what you've written your input won't matter very much anyway. No matter what you do they will hand you broken software at the end of their process. Upper managment is saying, by their actions, that they don't care whether their software division is competent. Think of cooperating as playing a part in a bit of meaningless corporate theater.
posted by rdr at 9:03 PM on November 13, 2007
posted by rdr at 9:03 PM on November 13, 2007
I am probably wrong, but it's possible that what your employer is proposing may contravene the DocuPub software license.
This is a far cry from illegal, but you could go over the EULA with a fine tooth comb and see if there's something in there that would make it "unethical" for you to comply with your company's request.
I personally would not resist this simple and seemingly legal request from my employer, but to each his/her own.
posted by OlderThanTOS at 9:18 PM on November 13, 2007
This is a far cry from illegal, but you could go over the EULA with a fine tooth comb and see if there's something in there that would make it "unethical" for you to comply with your company's request.
I personally would not resist this simple and seemingly legal request from my employer, but to each his/her own.
posted by OlderThanTOS at 9:18 PM on November 13, 2007
There is absolutely no way what this programmer is asking for is illegal, unethical, or in any way shady. It's the right thing to do.
However, the way he's going about it is dumb. He should be looking at DocuPub himself, not asking you to take screenshots of it for him. Why don't you suggest that he do that instead?
posted by ook at 10:45 PM on November 13, 2007
However, the way he's going about it is dumb. He should be looking at DocuPub himself, not asking you to take screenshots of it for him. Why don't you suggest that he do that instead?
posted by ook at 10:45 PM on November 13, 2007
Thank god this stuff happens all the time or the only people using computers with GUIs would be running Xerox Star hardware.
posted by 6550 at 10:56 PM on November 13, 2007
posted by 6550 at 10:56 PM on November 13, 2007
nthing it's totally legit. You should see it as an opportunity. If management does go down the "eat your own dog food" route, you're going to be using the software that the Shitty Software Division turns out.
So take this chance to explain to them how you use DocuPub in your workflow; what functions you use regularly, what works well for you and what doesn't, what things you just couldn't live without. If they don't get that sort of user input, you're going to get some programmer's idea of your workflow, and trust me, it's going to suck.
I've been on both sides of this problem and things work a LOT better if the future-users and the developers talk to each other throughout the various stages of the process. Go into this with an open mind and maybe there's a chance good things will happen. But if you go into it with a bad attitude, you'll probably only hate yourself later when you're stuck with some PoS product and your productivity falls through the floor and you take the blame because the software people covered their ass by producing your design documents as proof they met requirements. Mmmkay?
posted by Kadin2048 at 11:16 PM on November 13, 2007
So take this chance to explain to them how you use DocuPub in your workflow; what functions you use regularly, what works well for you and what doesn't, what things you just couldn't live without. If they don't get that sort of user input, you're going to get some programmer's idea of your workflow, and trust me, it's going to suck.
I've been on both sides of this problem and things work a LOT better if the future-users and the developers talk to each other throughout the various stages of the process. Go into this with an open mind and maybe there's a chance good things will happen. But if you go into it with a bad attitude, you'll probably only hate yourself later when you're stuck with some PoS product and your productivity falls through the floor and you take the blame because the software people covered their ass by producing your design documents as proof they met requirements. Mmmkay?
posted by Kadin2048 at 11:16 PM on November 13, 2007
A few random options:
1. Do your divisions bill one another? If they do, then send them an estimate for what your analysis will cost in your very valuable hours + opportunity cost for what you should be doing instead.
2. Send them the analysis that you've already given them with a few fuzzy, lo res screen grabs (perhaps taken from DocuPub's website). A shitty division deserves shitty analysis.
3. Try and find a Very Important Project with a Very Important Client to get involved in.
4. Instead of doing a software analysis, do a cost analysis of making the entire shitty division redundant and buying your software commercially. Give this to the decision maker within Shitty Division, and tell him/her that you expect to be left alone in future, or you'll take your downsizing plan to management and pursue it with a zeal.
5. Whenever they ask you for it, say you are working on it. Then don't ever work on it.
posted by happyturtle at 11:46 PM on November 13, 2007
1. Do your divisions bill one another? If they do, then send them an estimate for what your analysis will cost in your very valuable hours + opportunity cost for what you should be doing instead.
2. Send them the analysis that you've already given them with a few fuzzy, lo res screen grabs (perhaps taken from DocuPub's website). A shitty division deserves shitty analysis.
3. Try and find a Very Important Project with a Very Important Client to get involved in.
4. Instead of doing a software analysis, do a cost analysis of making the entire shitty division redundant and buying your software commercially. Give this to the decision maker within Shitty Division, and tell him/her that you expect to be left alone in future, or you'll take your downsizing plan to management and pursue it with a zeal.
5. Whenever they ask you for it, say you are working on it. Then don't ever work on it.
posted by happyturtle at 11:46 PM on November 13, 2007
If your boss doesn't want you dealing with these people, and you don't have time to deal with these people, there's nothing much to do.
Better, then, to either loan them a copy (assuming you have a spare license) so that they can do their own research, or suggesting that they buy an additional seat license for that purpose.
posted by davejay at 12:04 AM on November 14, 2007
Better, then, to either loan them a copy (assuming you have a spare license) so that they can do their own research, or suggesting that they buy an additional seat license for that purpose.
posted by davejay at 12:04 AM on November 14, 2007
Keep in mind that if you refuse to describe how docuPub works, then your shitty software division has a perfect excuse for not providing you with the software you need. You may actually be harming your branch and giving them cover by not providing them with the information they've asked for.
posted by seanyboy at 12:40 AM on November 14, 2007
posted by seanyboy at 12:40 AM on November 14, 2007
Tell them to just get their own copy? They'd learn far more using the software than recieving a document from you with a bunch of screenshots
posted by missmagenta at 1:57 AM on November 14, 2007
posted by missmagenta at 1:57 AM on November 14, 2007
It sounds like the software guys are either trying to get you to do their jobs and/or looking for someone to blame for the eventual failure of the product. I would send an email back saying:
'Here are the specs that I originally sent. I can confirm that DocuPub provides the functionality required to meet these specs. However, I think that the detailed analysis of how this is achieved is a task best performed by a specialist. I have a spare license of DocuPub that you may have to help you with your study.'
If you have the backing of your boss, this should be enough to get you out of it.
posted by Jakey at 2:18 AM on November 14, 2007
'Here are the specs that I originally sent. I can confirm that DocuPub provides the functionality required to meet these specs. However, I think that the detailed analysis of how this is achieved is a task best performed by a specialist. I have a spare license of DocuPub that you may have to help you with your study.'
If you have the backing of your boss, this should be enough to get you out of it.
posted by Jakey at 2:18 AM on November 14, 2007
While I agree with everyone that what they're asking is not only legal but (from their perspective) a good idea (although them trying to learn from it personally would be even better) I'll play a bit of the Devil's advocate:
You've just had a GOLDEN opportunity dropped in your lap. They've just asked you not only to do the concepting portion of their job for them, they've asked you to tell them what their job is. This is your chance to demonstrate to them that they have little hope of actually creating what it is you want.
Go over the features and workflow of DocuPub, in detail, explaining how each is absolutely critical to your job and you cannot live without. Go completely over the top with your thoroughness. Be sure to include functionality caveats on each so that you don't get hit with a clone of DocuPub that requires multiple inputs of the same data, or an equivalently botched implementation for each given feature.
Don't just go into details about features - express some of the systemic relationships between them that make DocuPub a Good Thing from a holistic perspective. Make those relationships a mandatory part of the spec.
Most importantly: make every piece of functionality mandatory to you and your entire department effectively performing your jobs. Your goal here is to give them so much information, and make each aspect seem so critical, that they despair of ever pulling it off. If you inflate their perception of the scale and scope of the undertaking, there is a very good chance they may back off, or take so long to do it that upper management cuts their losses on the project.
Stay late one night, or two, or work a Saturday, and in 8 to 10 hours you should be able to crank out something amazingly and excessively thorough. Nobody at all can complain that you haven't gone way above the call of duty to service them.
Finally, make sure your boss knows what you're doing. If he's either privately or publically expressed a dislike of past results, pull him aside and tell him that you think you have a golden opportunity here to force them to either write something decent for once or abandon the project entirely.
If he's as good as you make him sound, he'll see that this is exactly the case.
The best way to sabotage hard-working, competent people is to slack off or fuck up when they need you most. The best way to sabotage incompetent fools is to define their job such that incompetence or foolishness results in justified termination. You've been given the golden chance to define their jobs, so go out there and make them bleed tears or good software. Which of those two they choose is on their heads - and you shouldn't care which they perform so long as you've exploited your ability to limit their options to only those two.
posted by Ryvar at 2:39 AM on November 14, 2007
You've just had a GOLDEN opportunity dropped in your lap. They've just asked you not only to do the concepting portion of their job for them, they've asked you to tell them what their job is. This is your chance to demonstrate to them that they have little hope of actually creating what it is you want.
Go over the features and workflow of DocuPub, in detail, explaining how each is absolutely critical to your job and you cannot live without. Go completely over the top with your thoroughness. Be sure to include functionality caveats on each so that you don't get hit with a clone of DocuPub that requires multiple inputs of the same data, or an equivalently botched implementation for each given feature.
Don't just go into details about features - express some of the systemic relationships between them that make DocuPub a Good Thing from a holistic perspective. Make those relationships a mandatory part of the spec.
Most importantly: make every piece of functionality mandatory to you and your entire department effectively performing your jobs. Your goal here is to give them so much information, and make each aspect seem so critical, that they despair of ever pulling it off. If you inflate their perception of the scale and scope of the undertaking, there is a very good chance they may back off, or take so long to do it that upper management cuts their losses on the project.
Stay late one night, or two, or work a Saturday, and in 8 to 10 hours you should be able to crank out something amazingly and excessively thorough. Nobody at all can complain that you haven't gone way above the call of duty to service them.
Finally, make sure your boss knows what you're doing. If he's either privately or publically expressed a dislike of past results, pull him aside and tell him that you think you have a golden opportunity here to force them to either write something decent for once or abandon the project entirely.
If he's as good as you make him sound, he'll see that this is exactly the case.
The best way to sabotage hard-working, competent people is to slack off or fuck up when they need you most. The best way to sabotage incompetent fools is to define their job such that incompetence or foolishness results in justified termination. You've been given the golden chance to define their jobs, so go out there and make them bleed tears or good software. Which of those two they choose is on their heads - and you shouldn't care which they perform so long as you've exploited your ability to limit their options to only those two.
posted by Ryvar at 2:39 AM on November 14, 2007
One other thing:
Request, with your boss's permission (since this will eat into your time), the 'opportunity' to evaluate their pre-alpha (you can very very subtly imply that this is the reward expected for your overwhelming assistance). If they actually turn out something decent then you've got the chance to make it better. If they turn out crap, you've just given yourself an early veto power.
One other thing about the above: 10 hours should be sufficient time to churn out 25-30 pages of dense 10-point Times New Roman workflow spec with big chunky paragraphs. You'll have to be careful not to repeat yourself or wax garrulous, but that and about 20 screenshots should hit the critical length required to make their eyes glaze over.
posted by Ryvar at 2:51 AM on November 14, 2007
Request, with your boss's permission (since this will eat into your time), the 'opportunity' to evaluate their pre-alpha (you can very very subtly imply that this is the reward expected for your overwhelming assistance). If they actually turn out something decent then you've got the chance to make it better. If they turn out crap, you've just given yourself an early veto power.
One other thing about the above: 10 hours should be sufficient time to churn out 25-30 pages of dense 10-point Times New Roman workflow spec with big chunky paragraphs. You'll have to be careful not to repeat yourself or wax garrulous, but that and about 20 screenshots should hit the critical length required to make their eyes glaze over.
posted by Ryvar at 2:51 AM on November 14, 2007
Response by poster: Sounds great Ryvar, but doesn't mean shit if Management decides to act like idiots and let shitty software division do the usual shitty work.
posted by MichaelKnight at 3:55 AM on November 14, 2007
posted by MichaelKnight at 3:55 AM on November 14, 2007
Sounds great Ryvar, but doesn't mean shit if Management decides to act like idiots and let shitty software division do the usual shitty work.
Welcome to the world of Buy or Build. We face these kinds of decisions every month, only the situation is usually reversed: we'd rather build a quality application ourselves than let some incompetent outside firm mess it up with their grubby paws.
I can't really help you with convincing management except to suggest that your development team's time might be better spent on other projects with higher business priority. Traditionally, though, when given the choice between two options, management will always pick the worse of the two (it's like an instinct).
The best you can do is CYA. I'd suggest writing up a list of requirements that looks remarkably similar to DocuPub, so that the choice is obvious. Then, when management still chooses to be idiots and let your craptacular devs take a stab at it, they can use the project timeline to check their progress. If they aren't anywhere near completion a month before it's due, they might have a change of heart.
At the very least, if you still wind up with a shitty piece of software you aren't the one they blame and your head isn't the one to roll.
posted by Civil_Disobedient at 5:36 AM on November 14, 2007
Welcome to the world of Buy or Build. We face these kinds of decisions every month, only the situation is usually reversed: we'd rather build a quality application ourselves than let some incompetent outside firm mess it up with their grubby paws.
I can't really help you with convincing management except to suggest that your development team's time might be better spent on other projects with higher business priority. Traditionally, though, when given the choice between two options, management will always pick the worse of the two (it's like an instinct).
The best you can do is CYA. I'd suggest writing up a list of requirements that looks remarkably similar to DocuPub, so that the choice is obvious. Then, when management still chooses to be idiots and let your craptacular devs take a stab at it, they can use the project timeline to check their progress. If they aren't anywhere near completion a month before it's due, they might have a change of heart.
At the very least, if you still wind up with a shitty piece of software you aren't the one they blame and your head isn't the one to roll.
posted by Civil_Disobedient at 5:36 AM on November 14, 2007
Michael , You haven't given a clear reason why you don't want to help the software division, except "I don't like them". It sounds like petty politics have gotten to you. As an organization, cutting costs is what they do and in-house makes sense if it achieves this end. No one knows what exactly your job is in that organization. If it's not your job, then don't help. But you said you are the most knowledgeable about the software so you should help.
Other-wise you are making yourself a liability. If I was the top boss I would move to replace the staff at software div. if they were incompetent, or anyone that hindered progress or fueled discord with their petty politics and that may include you.
posted by Student of Man at 9:04 AM on November 14, 2007
Other-wise you are making yourself a liability. If I was the top boss I would move to replace the staff at software div. if they were incompetent, or anyone that hindered progress or fueled discord with their petty politics and that may include you.
posted by Student of Man at 9:04 AM on November 14, 2007
Response by poster: SoM,
I don't want to help this software division because when I've spent the hours doing previously it was ignored. despite endless meetings and hashing out a spec. I am not a programmer, if they can't figure out what are seemingly basic questions to this CS layperson, then I actually can't help them
If it makes you feel better, I wrote up an email answering their questions in some detail and then offering what I thought would be a better solution for the company. This email bounced, saying the user who had sent this email two days ago didn't exist. I looked him up in the Outlook directory, compared emails, they were the same, but what the hell, tried again, still boucned. CC'ed the boss on the email, calling it a day.
posted by MichaelKnight at 1:55 PM on November 14, 2007
I don't want to help this software division because when I've spent the hours doing previously it was ignored. despite endless meetings and hashing out a spec. I am not a programmer, if they can't figure out what are seemingly basic questions to this CS layperson, then I actually can't help them
If it makes you feel better, I wrote up an email answering their questions in some detail and then offering what I thought would be a better solution for the company. This email bounced, saying the user who had sent this email two days ago didn't exist. I looked him up in the Outlook directory, compared emails, they were the same, but what the hell, tried again, still boucned. CC'ed the boss on the email, calling it a day.
posted by MichaelKnight at 1:55 PM on November 14, 2007
This thread is closed to new comments.
Shitty companies will build shitty products regardless of how well they understand what the product is supposed to do. If i were you, I'd do it just to cover my own ass.
posted by unexpected at 7:25 PM on November 13, 2007