|
Any suggestions for management difficulty?
Hi everyone.
I work with a programmer who's product I distribute. I am also a programmer, in addition to doing marketing, sales, etc.
I've had some challenges working with this programmer and I'd like to get some feedback and suggestions.
The programmer is very pleasant and this program is a sideline for her. But it gets frustrating at times.
Bear in mind that the programmer gets about a 50% royalty. I see my job as marketing and sales and hers as programming. She's an experienced Java programmer with over a decade of experience in C++. I assume she' competent.
CHALLENGES
1. UI Difficulties
I give her specific languge and instructions and she changes the language to something less clear. She also complains about the difficulty of implementing what I suggest. When I offer an alternative she ignores it. When I offer to brainstorm on the phone (she lives out of town) she ignores the offer.
2. Insufficient testing
Programmer gives me code that has errors that indicate she never tested it. I find the errors within 5 minutes usually. This happens just about everytime I get something from her.
3. She can't keep track of tasks.
She seems to forget a lot of tasks that I email her. Even when I summerize the tasks for her and organize them with nice, simple labels to track them by. So, the'll forget to implement something.
QUESTIONS
1. Is this a typical problem with outsourced work?
Perhaps this is just the reality of outsourced work.
2. Any suggestions of how to handle this?
Bottom line is that I don't make much money off this product, I giver her a bigger royalty than our other third party product and the other product has far fewer problems.
Mr. Analogy
Monday, May 17, 2004
Um, who's the boss, you or her?
old_timer
Monday, May 17, 2004
1. It's a problem most every manager has faced at some point. I think outsourcing just magnifies the problem. It reaches a state beyond what it would reach if you were down the hall.
2. Take advice from Dear Abby and send her what you wrote? That's written tongue in cheek, but only partly.
Sounds to me that it's not an intelligence problem, but an ego problem. She doesn't want to work on the details, and doesn't want to do what doesn't "turn her crank".
She's picking off the easy, low-hanging fruit, and will continue to do so (I imagine) until you come down on her.
Edward
Monday, May 17, 2004
Who is the boss? You have one problem if she is working for you, another if you are working for her, and another if it's a partnership. It would appear that there are other things on her plate that are more worthwhile paying attention to.
If you are seeing no profit, maybe the project should be discontinued.
njkayaker
Monday, May 17, 2004
First politely indicate the problems you are having. Repeat the polite warning a couple of times. Then tell her frankly what the problems are and that you are rethinking the whole thing. If it still happens, hire someone else.
Be careful that you spell out the specifics each time. E.g A, B, C, D does not work. Atleast, she wont have a doubt on why you are distressed
K
Monday, May 17, 2004
Responses to the above:
To clarify: we sell a product she created. She couldn't sell it because marketing/sales/useability aren't her strength.
Product would sell better if it were a bit more useable. The changes I requested were to that end.
So... I am not exactly the boss. More of a partnership. However the buck stops with me. If I don't do my job then nobody makes a dime. If she drops the ball, I have to at least TELL her (repeatedly) to pick it up.
I think I'll try pointing out that my job is sales and marketing. Hers is programming. She needs to get it to me up to the spec we agree on bug free.)
Mr. Analogy
Monday, May 17, 2004
One approach is to make a list of proposed changes and meet with her to discuss them.
Only the changes agreed upon would be made.
Bascially, you want to make a "contract" about changes so that other (unspecified) changes are not made.
Is she clear on your "important" role?
njkayaker
Monday, May 17, 2004
Never met her in person. Too far to travel.
"Contract" would be good to specify what she should be doing and what i should be doing. Depending on legal enforcement to get her to do her work is not a good idea. You can't MAKE anyone do anything (certainly not do it *well*, anyway).
Mr. Analogy
Monday, May 17, 2004
Mr. Analogy, is Aussie Chick working for you?
Philo
Philo
Monday, May 17, 2004
I don't think Aussie Chick does Java, and as I recall she is imminently concerned about usability :-)
Scot
Monday, May 17, 2004
Mr. Analogy,
It seems like the developer doesn't think your ideas will increase revenue on par with the effort put into it...
So the question would be: do you both have similar ideas of how much the changes would increase revenue? If not, then you could offer to pay her upfront for the changes in addition for keeping the additional revenue yourself.
On the other hand, if you do have similar ideas on how much revenue will increase and she is still unmotivated, then perhaps she thinks her time is worth more than the time required to make the changes.
Scot
Monday, May 17, 2004
"addition" = "exchange"
Scot
Monday, May 17, 2004
>> When I offer to brainstorm on the phone (she lives out of town) she ignores the offer.
Has it always been like this? I think most programmers are quite happy to brainstorm about their programs, so this seems like a sign of lack of interest. Maybe she's just a bit burned out and could use some rest from the project?
Matt
Monday, May 17, 2004
I was not suggesting a legal contract (hence the quotes). Basically, you are trying to get a commitment, that is, an agreement that the changes make sense to do and that they will be done.
How often are changes being requested? It's possible that you'd get "better performance" batching the changes together and making fewer requests.
njkayaker
Monday, May 17, 2004
Sounds like classic passive resistance to me. My guess is that you'll get the best results by sucking up to her. Make her think you're her biggest fan, everything she does is wonderful. And read up on Project Managers/herding cats...
Tom H
Monday, May 17, 2004
She's probably lost interest in the whole thing as a commercial venture. The royalties probably aren't enough to sustain her interest. Since it is a sideline, she probably doesn't really need the money. She may have completely lost interest or she may be doing it in the hobbyist/open source style where she does what she wants, when she wants. Since she ignores you, she clearly is not interested in doing the bare minimum to be a credible business. You are in business with somebody who doesn't want to be in business.
She owns the source code. That's what she has. You are the single, exclusive distributor. That's what you have. If you fight, she can refuse to let you sell the program and you can refuse to sell the program. But, I'd suggest that you be nice and not fight.
I'd suggest:
Ask her directly if she's lost interest. If she has and she's something of a friend, try to convince her to sign the source code over to you so you can get somebody else to work on it. If not, offer to pay a nominal fee: $500 or whatever to get the source code. If she tries to hold out for more money than you think that its worth, walk away. If you hang in there, you'll probably waste more time trying to get an uninterested person to do things.
Frankly, I expect that you'll just end up walking away. She won't want to make your changes but she won't want to give up the code. She'll probably over-estimate its value and try to hold out for a king's ransom.
In the future and if you do not do so already, I'd suggest that you either (1) own some rights to a few products that you sell so a single person will not be a roadblock or (2) carry lots of different products so you can drop providers who lose interest without much trouble.
Daniel Howard
Monday, May 17, 2004
Overall, it appears that you are trying to manage her is if she was your subordinate, yet you mentioned that you're in fact at least equal partners.
"Specific languge(sp) and instructions" can drive certain people nuts in such circumstances.
"She also complains about the difficulty of implementing what I suggest." - And you're apparently disregarding such feedback from her.
"When I offer an alternative she ignores it." - She is a creator in the whole thing, and does not like to be told what to do.
"When I offer to brainstorm on the phone (she lives out of town) she ignores the offer." - There is nothing worse than "brainstorming" with people who have not got a clue. Are you sure that you're sufficiently knowledgible to offer good suggestions? I avoid like hell such discussions with clueless but pushy people, because later they start insisting that I should be doing what they suggested, whereas in my opinion there was no merit in what they offered. And constantly explaining why I am not gonna do it is a huge drain of my energy and time.
Your best bet is to try to "sell" the idea of the updates to her, and to make sure that she is 100% behind it. The only thing that can work here is persuasion. Drop your current tactics, they are counterproductive.
Also, "insufficient testing" is all you can expect from her, thorough testing is time consuming as hell. That is why companies have seperate testers. And you could probably take care of some testing yourself, it is not rocket science.
"She can't keep track of tasks." - She is probably an artistic type, so your best bet is to patiently resummarize to her what remains to be done if she agreed to it.
"Bottom line is that I don't make much money off this product." - Perhaps you should have a direct convo with her about this, and ask her opinion on how to proceed. Sometimes there is no use in making unsatisfying arrangements work, and letting go is the best option.
Mr Curiosity
Monday, May 17, 2004
"Overall, it appears that you are trying to manage her is if she was your subordinate, "
No, I'm just a distributor who expects that the product he distribute not require testing. She should deliver it in working order.
""She also complains about the difficulty of implementing what I suggest." - And you're apparently disregarding such feedback from her."
-----
Ummm.... no, I recognized the difficulty and suggested an alternative.
"When I offer an alternative she ignores it." - She is a creator in the whole thing, and does not like to be told what to do."
-----
Ummm... it's an alternative to MY suggestion. I think you're missing what I wrote. Try rereading it again.
"Your best bet is to try to "sell" the idea of the updates to her, and to make sure that she is 100% behind it. The only thing that can work here is persuasion. Drop your current tactics, they are counterproductive."
I'm confused. What tactics?
I haven't commented on my "tactics" but here's what I emailed her at the begining of the changes:
I requested changes, explained that "you've written a great program. It has some amazing features, but no one knows aobut them. We need to make users aware of the cool stuff".
"Also, "insufficient testing" is all you can expect from her, thorough testing is time consuming as hell. That is why companies have seperate testers. And you could probably take care of some testing yourself, it is not rocket science."
Hmmm... I found two show stopper bugs in less than 5 minutes. I should have said she did NOT testing, but I was being kind. I'm not asking for exhuastive testing. Just TRY THE FEATURE.
I'm the distributor. I don't ask her to go to conferences and present the software. Likewise, it's simply not my job to test her software. I know software testing is hard. So is sales and marketing and tech support. All of which I do.
"She can't keep track of tasks." - She is probably an artistic type, so your best bet is to patiently resummarize to her what remains to be done if she agreed to it."
Did you read my original post?
From my post: [She loses track of tasks] "Even when I summerize the tasks for her and organize them with nice, simple labels to track them by. "
Perhaps you should have a direct convo with her about this, and ask her opinion on how to proceed.
Yes. This is excellent advice. Summary below.
Mr. Analogy
Monday, May 17, 2004
"She" that's the problem right there!
Me, myself and Irene
Monday, May 17, 2004
"No, I'm just a distributor who expects that the product he distribute not require testing. She should deliver it in working order."
Don't expect anything and you won't be disappointed. She is flaky, so you need to deal with her in a more failure tolerant manner. You already know when and how she fails, so incorporate this into your plans.
"Ummm.... no, I recognized the difficulty and suggested an alternative."
"Ummm... it's an alternative to MY suggestion. I think you're missing what I wrote. Try rereading it again."
How is that I am missing anything here? The alternative is still YOURS, so this is technically still YOUR suggestion, even if it is not the original one ...
"I'm confused. What tactics?"
With your approach (tactics) you're trying to make her operate according to your expectations, instead expect her being flaky and adjust accordingly.
"I requested changes, explained that "you've written a great program. It has some amazing features, but no one knows aobut them. We need to make users aware of the cool stuff"."
This is way too broad, she probably did not buy it. No specifics, you sounded like a salesman. Believe it or not some people develop heavy resistance against such happy face comments.
"From my post: [She loses track of tasks] "Even when I summerize the tasks for her and organize them with nice, simple labels to track them by. ""
Again, you are trying to make her perform efficiently according to your expectations. She probably does not like that, and may even be ignoring difficult tasks on purpose. Creating an easy to track "Done" list still does not mean she agreed to the changes you want her to implement ...
You're partners, you need to direct her gently without her feeling managed.
I am not against you personally, just trying to point out why the situation is working out like this ...
Mr Curiousity
Monday, May 17, 2004
Mr Analogy, who's idea was it that you "distribute" her product? I bet it was yours.
Monday, May 17, 2004
There's some room for ambiguity in the back-and-forth on feature requests.... maybe she doesn't like what you're suggesting, maybe it's harder than you think, maybe she's just bored, maybe she's super busy with other things, etc.
But giving you a non-working product is ridiculous. Of COURSE testing is part of her job, it's HER source code. How does she expect to stay in business, giving you a buggy product to distribute? What would happen if you sold it to customers without testing??
My guess is that she DOESN'T want to stay in business, as previous posters have suggested. She just doesn't care about this product. So, you have no leverage with her. I would try a direct conference with her about all this, then drop the product if you see no change.
Biotech coder
Monday, May 17, 2004
If I were you I'd tell her that since you are not the tech person here, she is, it only makes sense that all tech support questions get sent to her.
Sell the product exactly as she gives it to you and forward all questions to her.
The pain she will endure as a result will make her either improve the product or give up on it completely. Either way, you win.
Aaron F Stanton
Monday, May 17, 2004
"If I were you I'd tell her that since you are not the tech person here, she is, it only makes sense that all tech support questions get sent to her.
Sell the product exactly as she gives it to you and forward all questions to her.
The pain she will endure as a result will make her either improve the product or give up on it completely. Either way, you win. "
Aaron,
That sounds good in theory. The reality is that my company has a great reputation in a small niche. I'm unwilling to put MY reputation on the line in that manner. MY company will get the blame when HER product has difficulties.
In general, setting up a feedback loop like that is a great idea. I just don't want to be the conduit through which the feedback travels <g>.
Mr. Analogy
Tuesday, May 18, 2004
Mr. Curiosity,
Let me see if I'm understanding you correctly:
1. Accept that the programmer has certain limitations. She doesn't test her software for obvious bugs. She doesn't execute changes that we've agreed upon (perhaps because she's not "signed up" as they say at Microsoft)
2. Work within these limitations.
3. Try to persuade her do do what I want.
These are all very reasonable approaches.
HARD TO FIND GOOD HELP
If you hire an employee, then you need to manage them, oversee them, etc. Takes up a lot of time. That's just how things work. (IF you read The Gifted Boss, it explains why this is natural).
If you find a partner, then it's essential that you work together productively and enjoyably.
I thank you for all of your suggestions.
I just realized that I really don't enjoy having to constantly sell someone on the benefits of making software easy to use.
I love teaching: opening people's eyes. But this is different. The programmer just doesn't get the idea that there is a benefit to making software easy to use.
Mr. Analogy
Tuesday, May 18, 2004
"Bottom line is that I don't make much money off this product."
Hm, and sense you are equal partners, what can we conclude about how much money SHE makes off this product??
So tell me -- given that you have done an incompetant job of marketing the product (otherwise there would be greater sales), explain what her motivation is to do a lot more work at no pay to improve a product that you aren't doing a good job of selling?
Sorry but i'm on her side on this one - you are the problem. You are no good at marketing AND you are expecting her to do much work for free. That's a suckers deal.
Dennis Atkins
Tuesday, May 18, 2004
Dennis is right, Mr Analogy. You're a multimedia groupie with no understanding of complex software product development. I understand this one is in Java, which is outside your area of expertise.
You think some change is trivial. It's probably going to take 2 days.
Guys like you are responsible for a lot of the complaints on this forum.
Cruel to be kind
Tuesday, May 18, 2004
"I love teaching: opening people's eyes. But this is different. The programmer just doesn't get the idea that there is a benefit to making software easy to use."
This benefit is not at all apparent to many programmers. To you it means increasing sales, to her - whole bunch of boring work trying to make small pieces of the interface work as intended.
A lot of geeks find interface development unrewarding, and thus try to avoid it.
If you could be more specific to her, and explain how such and such customer did not by the product because of such and such interface issues, she might have listened. Otherwise there is no limit to perfection, and in your quest to be flashy in your presentations of the product you may want features from her which may not be that useful, but you deem them valuable because of their presentation value. She would not perceive such value at all.
Mr Curiosity
Tuesday, May 18, 2004
"Dennis is right, Mr Analogy. You're a multimedia groupie with no understanding of complex software product development. I understand this one is in Java, which is outside your area of expertise.
You think some change is trivial. It's probably going to take 2 days.
Guys like you are responsible for a lot of the complaints on this forum. "
-------
1. I've been programming for about 10 years now.
2. I've written 18 programs.
3. On average THOSE programs EACH generate about 4x the revenue of her program.
4. I get twice as many support calls on her program as any other program (per program). That means fewer calls about bugs. Fewer calls about "how does this work", etc.
5. You have no idea of my skill at marketing or sales, or programming.
6. The change I suggested IS trivial, at least in VB or Delphi. She's using C++ so I *assumed* that it would indeed take her longer.
Mr. Analogy
Tuesday, May 18, 2004
OH, BTW, the reason I know the change would be trivial in VB or Delphi is because I can make the change in VB or Delphi. And have done so in other programs.
Mr. Analogy
Tuesday, May 18, 2004
Hmm.
Define 50% royalty ? If it's her system then she should get the royalty and you should get the balance from the sale.
Maybe she thinks you are taking a bigger slice than your added value is worth. IMHO sales people tend to oversell their benefit, even to themselves. Is this a case of 'hey babe, you wouldn't make a penny without me, so I'll take what I want' ? If so then I can hardly blame her for being demotivated.
Second. If she wrote a product that you have seen fit so sell, she must have been pretty good to start with, that would suggest that it's her relationship with you that is the problem, not her skill level.
Third, if she developed this from scratch as implied by 'it's her product' then maybe she's just an ideas person. Maybe you should be giving her time and money to develop some new idea and passing on the maintenance to someone diligent and unimaginitive.
WoodenTongue
Tuesday, May 18, 2004
"Dennis is right, Mr Analogy. You're a multimedia groupie with no understanding of complex software product "
How on earth would you even know?
You don't even know what the change was.
"development. I understand this one is in Java, which is outside your area of expertise."
I never said it was in Java. There goes another assumption.
It's in C++.
"You think some change is trivial. It's probably going to take 2 days."
I could make the change in vb or delphi in 30 minutes (including testing it).
I know you C++ coders take longer to do things, but I don't think a 16x factor is realistic.
Guys like you are responsible for a lot of the complaints on this forum. "
That' the difference between EMPLOYEES and OWNERS.
Employees bitch about how everything is someone else's fault.
I posted and asked if this was typical and how *I* might handle it.
Many of the respones were "just accept that she's flawed".
I suspect you wont' find a post from her (no she isn't Aussie Chick) on how SHE could solve the problem.
Ok. I've got to go solve this problem.
Mr. Analogy
Tuesday, May 18, 2004
The person or group responsible for drawing up the requirements should also be responsible for writing the acceptance test plan, and should NOT be the person or group writing the software (this is a conflict of interest). It appears that Mr. Analogy isn't formalizing the requirements, and the programmer is redefining them as she sees fits (i.e. to make the work as simple as possible and not conflict with the original product vision).
The problems Mr. Analogy encountered are not unique to outsourcing -- outsourcing merely magnifies the problems. Software projects require good project management to be consistently successful. Recommend taking a look at the resources list at: http://www.construx.com/professionaldev/organization/pdl/version1/reading-program-manager.htm
For GUI issues, the book "GUI Bloopers" by Jeff Johnson is a good read, as is Apple's Human Interface Guidelines at: http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/
Derek
Tuesday, May 18, 2004
Even if you think Mr. Analogy could be wrong in some respect, couldn't you answer politely ? It stills amazes me to see how some people can make peremptory assertions based on mere assumptions. For troll-lovers, there are Linux-vs-MS threads out there.
Pakter
Tuesday, May 18, 2004
> That' the difference between EMPLOYEES and OWNERS.
> Employees bitch about how everything is someone else's fault.
There's also a tendency for salespeople to bitch about how they can't sell a program because it doesn't have feature X, Y & Z. In other words, they make it someone else's fault when they can't sell something! Did you know that the program needed these features *before* you took it on and did you discuss this with the programmer at the time?
Since you appear to have had some disagreement over how difficult it would be to add these new features, perhaps she's sending you buggy code as a way of communicating to you that there are no "quick changes" - they need to be written, debugged, tested, documented and so on. If that's the case, she's not going about it in a professional way but perhaps she feels that it's the only way to get you to listen to her.
It's notable that you characterize this relationship as "outsourcing" when it sounds more like an equal partnership. If it's not working you need to discuss the matter openly, respect her views and back out of the relationship if it's going nowhere.
_
Tuesday, May 18, 2004
Derek,
Thanks. Very good point. Best suggestion so far. Often such a test is overlooked. No one wants to do it b/c it's boring.
BTW, "test driven design" is a GREAT answer to this. Write AUTOMATED tests while in the design stage. Helps to slow you down when you need to go slow (during design) and frees you to zoom during the final testing phase.
I subsequently wrote up an acceptance test.
Mr. Analogy
Tuesday, May 18, 2004
"There's also a tendency for salespeople to bitch about how they can't sell a program because it doesn't have feature X, Y & Z. In other words, they make it someone else's fault when they can't sell something!"
YOU'RE RIGHT...BUT I MAKE CHANGES TOO.
You are quite right. I deal with both sides, even with the same people. We have a distributor who's product we distribute. But when they suggest something, I carefully consider whether it will help all customers. I almost always include the feature.
BTW, one feature I requested of a different developer was : auto starting when you put the CD in. Their developer said, for about a year, "that it couldn't be done b/c it was a dual mac/pc cd". Then miraculously it had the feature. That was a HUGE improvement. You can't imagine how hard it is to explain to grandma Smith how to find her CD drive in Windows Explorer and double click "no, you have to click with your left mouse button twice FASTER. No, your other LEFT." Sigh...
THE CHANGES ARE NEEDED
The requests I make are based on objective measurements. I look at how many customers have a problem. The autostart was a prime example. I probably had 5% to 10% of those sales calling up to ask how to start it. That's an expense, but more importantly it's a huge black eye for the company that they even NEED to call.
FEATURES WILL HELP PROGRAM...MAY HELP SALES
I can't guarantee that we'll sell a lot more of the program. I can guarantee that the customers will have an easier time accessing the features that makes the program uniquely powerful.
" Did you know that the program needed these features *before* you took it on and did you discuss this with the programmer at the time?""
No, I did not. As I got feedback from customers I realized that they didn't understand how to use certain features.
"...perhaps she's sending you buggy code as a way of communicating to you that there are no "quick changes" - they need to be written, .... ....perhaps she feels that it's the only way to get you to listen to her."
Possible, if she has the social skills of an 8 year old. Seriously, we're all grownup professionals, I expect her to act like a professional, not a passive agressive 8 year old.
What do you think I didn't listen to her about?
(After talking to her she basically said she was really busy and didn't have time to test. But this has happened every time she has sent me code. Either with changes I requested or features she has added on her own.).
"...you characterize this relationship as "outsourcing" when it sounds more like an equal partnership. "
Quite right. Actually, I meant that this gives me some insight as to whether outsourcing can work. Or at least, how difficult it is to make it work.
I view her as a partner. All change requests have been just that: requests. I'm not even asking for more features, just MORE USEABILITY. And rather than have her change the interface, I'm just asking to give the user a HINT of how to use the feature.
Mr. Analogy
Tuesday, May 18, 2004
One more thought:
I wonder if it would work better if you give a programmer broader requirements:
8 out of 10 <lawyers, doctors, whatever the target customer is> would be able to find the following features if they knew the feature existed:
A.
B.
C.
This gives the programmer greater flexibility but it's harder for them to test. They may simply ASSUME they know how a lawyer thinks.
After having done a LOT of tech support, I have a pretty good feel for what the customer will find confusing (certainly what they currently find confusing).
One of the XP programming tenents, as I recall, is "immediate access to the customer, all the time".
I think that's pretty important requirement, but hard to satisfy.
Mr. Analogy
Tuesday, May 18, 2004
"I could make the change in vb or delphi in 30 minutes (including testing it).
I know you C++ coders take longer to do things, but I don't think a 16x factor is realistic."
Well, there's your solution right there. You are clearly a far more talented programmer than she is. You should do the coding and she can do the sales.
Problem solved.
Dennis Atkins
Tuesday, May 18, 2004
This thread is delusional.
First off, you are not outsourcing development to her. What a crock of shit it is to use that term. What is happening is she is outsourcing marketing to you. You are so full of yourself to say try and turn it around. Why do I say this? Your own words: "To clarify: we sell a product she created." SHE creat-ED the product. You are merely selling it. Know your place. Your place is not to tell her how to do her job. your place is to stop being an incompetant marketer and sell the madn program already so you both can make money rather than spend all your time explaining its flaws to her potential customers, you stupid stupid dimwit.
What the hell gave you the idea you were a marketer anyway? Shit, imbeciles like you really tick me off.
Royalties? It's her damn code! Not yours! You didn't pay her to develop it and you are not offering to pay her to add thesee features you want. SHE is paying YOU a COMMISION. "Royalty" is an ENTIRELY DIFFERENT CONCEPT. Tha fact that you do not understand something so basic shows how clueles you are to basic intellectual property issues.
Sheesh.
Dennis Atkins
Tuesday, May 18, 2004
"she's not going about it in a professional way"
I see no reason why anypone needs to behave in a 'professional way' when they are NOT BEING PAID for their work.
Damn, isn't that obvious? Profession implies you are getting PAID.
Dennis Atkins
Tuesday, May 18, 2004
Ok, look, I'll be helpful. You want the solution, I'll tell you the solution because it's pretty obvious. you watn her to make the changes, then you PAY her do to them. To make this make sense, you need to buy her codebase at the going rate. That is easy to calculate - C++ code costs between $4 and 60 per non-blank, non-comment line of code. Add up the lines of code in her project and that's your cost range to buy her out. On top of that, you work out a equitable ROYALTY structure at this point, and from here on out you pay her $120/hr to make the changes you want with all the acceptance tests and crap like that you want. Or hire someone else to maintain it, that's fine too.
Dennis Atkins
Tuesday, May 18, 2004
Mr Analogy, the things that rings alarms for me are 1) your presumption that you're the guy doing everything correctly and the other party is wrong ( always a give-away) and 2) the fact that you have a problem anyway, with such a seemingly simple transaction.
Cruel to be kind
Tuesday, May 18, 2004
"Aaron,
That sounds good in theory. The reality is that my company has a great reputation in a small niche. I'm unwilling to put MY reputation on the line in that manner. MY company will get the blame when HER product has difficulties.
In general, setting up a feedback loop like that is a great idea. I just don't want to be the conduit through which the feedback travels <g>. "
If you are unwilling to put company rep on the line and she will not work with you to improve the product, the situation must change in the interest of preserving your rep. If you deliver the product as-is, your rep will suffer.
I see only three ways to change this that will save your company rep:
(Do these only after determining that she won't improve her code without you inflicting a lot of pain.)
1. End the project immediately. You stop marketing it, all rights to the code revert to her, and you go your separate ways.
2. Offer to buy her side of the project for a reasonable price. If she balks, do one of the other two options. If it works, hire someone to do the job right and leave her out.
3. Offer to sell your side of the project for a reasonable price: Offer to put together a website and nice marketing package for a one time fee. If she accepts, do your job and wash your hands of it. Let her hire someone else to maintain the marketing aspect. If she balks, do one of the other two options.
The order of this is entirely up to you, but the way I see it you simply cannot continue the status quo without risking self-destruction.
Aaron F Stanton
Tuesday, May 18, 2004
 Recent Topics
Fog Creek Home
|
