Fog Creek Software
Discussion Board




Precious

I've just been hired (1.5 months ago) for a new project by a large financial institution in New York. I am a contracted developer, have been for 14 years.

My role was to develop the software from nothing to finished.

I came in, did the business requirements with the business, did the design, wrote the functional spec and technical spec, finished it all in good time with excellant accolades from my employer, the build is now merely a formality (well not really, but to me it is).

Problem is, my boss came up to me yesterday and said they now want one of their people (permanent) to do the build, based on my spec. He has shown an eagerness to 'learn' and it's a great opportunity to get on board with an experienced professional (no bragging intended).
I am supposed to hand hold and teach him through the process. The person they have nominated has 1-2 years development experience, I have about 15. The thing is I don't feel like sharing my libraries or build techniques with this person, I've learned them the hard way over many years, and they are factored into my rate, as what they end up with is a piece of good software, by any industry standard. What is NOT factored into my rate is teaching somebody else all the stuff I've learned over the years. To put it more precisely, I am happy to 'help' and 'teach' but not to 'give' my code libraries away, they are full of good stuff.

Am I being to precious?

Realist
Tuesday, April 29, 2003

>I am happy to 'help' and 'teach' but not
>to 'give' my code libraries away

Er ... what?

It seems to me that you are saying this:

1) "I deliver shipping software, not source.  If I 'help' this guy learn how to build, he's going to see the source, and I do not want to do that."

If #1 is the case, I think you can make a strong argument that no, your source code is propritary, and working with this person to "learn" would reveal propiretary, copyrighted information.  At the very least, you'll need a 50% pay raise for this. :-)

or
2) "I deliever source code and don't want to show him my make files."

  That's just wierd.  If you deliver source, you don't have much ground to stand on.  If I was in your shoes, I would just state that training a newbie takes time, so now you are going to ship 10, 20, or 30% late.  If you bill hourly, they'll pay 10-30% more, if you big fixed contract, that's scope creep, you can increase the price by 10-30%.


3) -- Something about your post sounds wierd.

A 1.5 month project?  That's pretty small.  The only thing left is the "build"?  What does that mean?  The testing phase?  Something about your post smells funny, but I can't put my finger on it. (You've been doing this for 15 years?  What did you do the last ten times this happened? :-)

With more information, perhaps I could explain #3 better.

regards,

Matt H.
Tuesday, April 29, 2003

"the build is now merely a formality"
 
  On re-read, this means "writing the source code and the testing phase", yes?

Matt H.
Tuesday, April 29, 2003

Yes.

You were employed to build and deliver an application, and (big presumption here) the source code, intellectual property, etc. belongs to the contracting institution.

Thus, your libraries, methods and procedures are (again a big presumption) part of the contract.

Pass on the skills and techniques. It will make you MORE, not less, valuable.

HeWhoMustBeConfused
Tuesday, April 29, 2003

If the employing entity was paying a consulting firm to provide the expertise you're providing, they would be paying a few hundred thousand.

Further, that consulting company would insist that its intellectual property be protected.

Never underestimate the stupidity of staff managers, who collect their pay cheques every month and don't see things broadly unless it's hammered home to them.

You need to sit them down and tel them what the deal is from here on in. Else you walk.

The Real Realist
Tuesday, April 29, 2003

Use some reverse psychology. If you don't want the guy your "mentoring" to take your ideas and libraries you should constantly talk about them to him. All day tell him how great the way you do things is and how he should change to your way. Over lunch print out the libraries and walk him through them.

A few weeks of this and you can guarantee that he will never want to do things your way. "You can lead a horse to water but you can't make it drink"

Matthew Lock
Tuesday, April 29, 2003

Ok I don't understand what the big deal is, being that I only have 2 years of professional experience - maybe I'm just being naive.

You don't want him to use your libraries.  So help him 'figure out' what he needs to do.  i.e. "Ok, so in the build process you're going to need to deal with X.  You'll need to write XYZ to deal with it." 

I don't think your 15 years of experience means you have some holy grail of a set of techniques or libraries - if you did, you probably wouldn't be a contractor, you'd be working for a Microsoft or an Oracle type of company.

As a contractor/consultant, you exchange your expertise for dollars.  If you're unwilling to help your client gain some proficiency - what's the value in having a contractor with 15 years experience?  None.  There's no room for this kind of crap in software development. 

Software development is hard.  That developer with 1-2 years experience isn't going to replace your knowledge/experience just because you explained a few of your techniques to him.

GiorgioG
Tuesday, April 29, 2003

Posturing aside, did they pay for it?  If so, give it to them, if not, they can squat and rotate!


Tuesday, April 29, 2003

From previous posts in this thread, let me summarize with "know the contract."    One of the biggest issues I need to resolve in consulting is knowledge transfer.  My position on this is crystal clear, if knowledge transfer is not part of a contract, the purchaser is making a serious mistake.  As consultants we do this for our reasons, and as clients, companies need to remove the illusion that they can dump contractors/consultants, when no one on their staff knows what the person does or how they do it.

However...(Always one of those)
If you are talking about precoded snippets, etc. that you have collected over the years, you need not "give" those away.  You can work with the developer from the company to construct everything.  In true "transfer of knowledge" they receiver needs to learn by .  Will this take longer? Probably, but it will benefit the other developer and the client in the long term.

If you take it on with a passion, it will also benefit you.  The company will see that when you show up they get a value add.  You do more than bill $X/hour.  You improve their staff.  This will get you invited back more often than being a good contractor.      It is a WIN-WIN if YOU make it so.

Mike Gamerland
Tuesday, April 29, 2003

Assuming that by "build" you mean implementing the spec., testing, rollout etc.
Seems you were paid as a contractor to deliver the spec. Now they want to hire you as a technical consultant to mentor the development  process. You can have a separate rate for this.
They did not ask you to do the development, so the code produced would come from the perm. right? You would set him up and guide him. Does not sound to me like they are asking you to bring your own IP to the process. If they do, that could be a separate billable item.

What is confusing me is the contradiction in your statements as to the "build" on the one hand being described as a mere formality, while on the other hand it would take your fiftheen years of accumulated experience, technique and background IP to pull it of. Which one is it?

Just me (Sir to you)
Tuesday, April 29, 2003

Another thing: the comment that passing on your skills and techniques will make you more valuable is complete fairyland stuff.

As soon as they don't need you any longer, they will kick you out the door. If they need you, they will pay you. This is the simple principle that everyone except developers seems to understand.

The Real Realist
Tuesday, April 29, 2003

What were you hired to do? To write software or to teach? If the former, then I would explain that teaching is a *significant* increase in job scope and you expect to be paid more commensurately.
In addition, if you have a hard/fast deadline, then dragging bob along is going to affect your ability to deliver on time. Is that an issue?
Also, who has authority on the job? If bob decides to use flat files instead of the Oracle server and the application is slower than molasses, do you get to hit him upside the head? If not, then do you get to disclaim him screwing up your app? (this is a big one - newbies will always try "some trick I read in a book somewhere")

Don't worry about "protecting your source code" - even the proof to Fermat's last theorem was published; nothing is *that* sacred. To insist that it is just makes you look self-important.

Philo

Philo
Tuesday, April 29, 2003

You have mixed together at least two entirely separate issues: intellectual property and instruction for what you seem to be implying is your personal library of code, which is now embedded in the program you've delivered; and instruction of the client's staff.


As far as the code library goes, what does your contract with the client say? Did you give the client a limited license to use your own library as part of the delivered application you built for them? Or is your contract mute about any contractor supplied code? If your contract is like most arrangements I've taken, you probably assigned IP rights to the client on everything you did on their nickel. Which is OK, as long as they know also that the solution includes your custom library. If you didn't notify them in writing in the contract that the delivered application was dependent upon this blob of code that they don't own that you are licensing to them, then my guess is that the client will assume that anything associated with the delivered application was custom written for them.  So, if you did not tell them that the job included your standard library, then you may well have lost the rights to the library in this instance.

Basically, you really needed to have covered this with them already. And again, it's a separate issue from the training. If I were you I would cover this with legal counsel.

As far as instruction of junior client staff - my opinion is that while I am not paid to baby-sit, the fact is that they've essentially signaled with this instructor role that they want to take over maintenance of the app themselves.  If you don't cooperate, your contract will likely just be ended and the greenhorn will simply be forced to learn on his own.

My experience with training really inexperienced people is that they simply don't learn that much. They absorb what they need to in order to do the immediate task, but nobody can really transfer 10+ years of experience into someone in a few chalk talk sessions. The point is, I don't think that you're "giving away" anything of substance that will compromise your position either with them or with any other client. Your knowledge likely goes much deeper than a few tricks used to build applications.

My $0.02.

Bored Bystander
Tuesday, April 29, 2003

Please expand on what you posted.

I thought I understood what you wrote until I got to the end of your post:

"...I don't feel like sharing my libraries or build techniques with this person"

"...To put it more precisely, I am happy to 'help' and 'teach' but not to 'give' my code libraries away, they are full of good stuff."

The above two statements are in conflict. Are you happy to teach your build techniques to this person or not?

Also, it sounds like you are saying that you had planned on only providing the executable files to your client and not the source code. Is this true?

What is inside your code libraries? Pre-built classes? Code snippets? Or something more extensive like application frameworks?

I am assuming the client wants their employee involved with the implementation work because he/she has been given the responsibility of maintaining this application after it has gone into production. Transferring your project knowledge to the full-time staff comes with the territory, however, it sounds like your client is asking you to go above and beyond the call of duty. Personally, I would simply break down the work into small tasks and then assign work to the client's employee. Your job isn't to teach this employee how to do software design. If that is what they are really asking you to do, then I would either ask for more money or be prepared to be shown the door after laying down the law .

Granted you are a contractor and not an independent consultant, however, with 15 years of experience under your belt you should know that these type of problems crop up because your employment contract was not modified by you!!!!!

As far as most clients are concerned, a contractor is a simply a "very temporary employee". In other words, you are expected to do whatever the client tells you to do -- just like a full-timer is expected to do. If this type of temp work sounds distasteful to you, then you need to negotiate your services before you start the work.

One Programmer's Opinion
Tuesday, April 29, 2003

If the new requests are not in your contract, then you are perfectly entitled to consider it a matter for negotiation. You can refuse but that might not be the best diplomatically. A far better tactic is to explain clearly that what they request is outside the scope of th original agreement and then name the price and terms for which you would be extremely ecstatic to provide them with the knowledge they seek. During negotiation, you can come down to the price for which you would be merely 'rapturously joyful' or 'moderately content' or whatever you personally are happy with. If they refuse, then you can move on without offending anyone or seeming unprofessional.

Note that at no point did I say your terms have to be reasonable to THEM. They just have to make you happy ias compensation for doing something you don't want to do.

I have used this tactic sucessfully many times and recommend it. I learned it from Gerry Weinberg, who is a man's man among consultants. Try it. Figure out what your terms are -- perhaps you would feel most comfortable if they sign a complex contract you have written outlining terms of licensing and secrecy (and damages if secrecy is not maintained) for your private libraries they will be using. And since you don't like teaching others, that means you will have additional expenses of alcohol and therapy each week to deal with your pain (joking but you get the idea), plus additional health insurance for the sickness that teaching the rugrat will bring on. That's costing YOU money and they need to compensate you for it. Perhaps your rate is $150/hl. Perhaps it is $365/hr. Perhaps there is a minimum of 100 hrs or 1000 at the rate. Who knows. You figure it out and let THEM be the ones to pay up or turn you down. You be the one to provide them with the options. You be the one in control.

Dennis Atkins
Tuesday, April 29, 2003

I don't understand why you would have a problem helping this kid out.  I assume you are getting paid for your services.  I've been in this industry for 12+ years now (as a fulltime employee and consultant for 7+ years) and I had the good fortune of working with people early on that taught me invaluable tricks and given me great knowledge.  I have learned a great deal from people with less experience than me as well as more experience than me.  I have always made the effort to pass along what I know with people that I work with.  You gain absolutely nothing from not helping this person out.  Ask yourself this question:  How much of what you know today came from other people and their experiences (think colleagues, websites, free source code, JOS)?  This industry requires the exchange of ideas and the free flow of information- I’m willing to bet that none of us got to where we are without others help.

If you don't buy that, try thinking of it this way: Someday that motivated kid with 1-2 years of experience will have 5-10 years of experience and be in a position to employ you/contract out opportunities!  I look fondly on the guys who shared their knowledge with me and would hire them/pass them jobs in a heartbeat.  I keep in contact with younger guys that now pass opportunities my way.

I think you'll find yourself further ahead by spreading the wealth and some good faith...

MikeG
Tuesday, April 29, 2003

>>  Someday that motivated kid with 1-2 years of experience will have 5-10 years of experience and be in a position to employ you/contract out opportunities!  I look fondly on the guys who shared their knowledge with me and would hire them/pass them jobs in a heartbeat.  I keep in contact with younger guys that now pass opportunities my way.

>> I think you'll find yourself further ahead by spreading the wealth and some good faith...

Yes.

I am as mean spirited, cynical and bottom-line oriented as they come. But I also think that this industry suffers greatly from lack of mentorship. Everyone wants to think they're self made, and nobody's willing to show newbies how things are done properly. Kind of a "f*** you" attitude or fraternity hazing mentality prevails. I think this industry is sick and suffers from a collective amnesia because mentoring is suppressed.

I can think of the huge number of times that I've wanted to shake the shit out of someone because they are doing things badly, ineptly, or without proper knowledge. I've wanted to help them get better just because it seemed wasteful to let them continue on damaging things, and it seemed like a sort of "pollution" to say nothing. But the chances to mentor people have been rare.

Generally, management wants senior developers (and especially contractors) to shut up and say nothing of substance. I'd personally run with an opportunity to spread some "goodness" and correct information around.  But that's me.

Bored Bystander
Tuesday, April 29, 2003

I agree, so long as "I was mentoring Jim" is an acceptable answer to "why is the project three months late?"

[Note that it doesn't necessarily have to be acceptable to *them* - just so long as their reaction to that statement is acceptable to *you*]

Philo

Philo
Tuesday, April 29, 2003

writing the source code and the testing phase is a formality?

ye gods....Ive only been in the programming business for 4 years but I live for the day I can make that statement with such complete confidence.

Some of your terminology is a little odd as well.....is english your second language?

best of all worlds
Tuesday, April 29, 2003

Philo said "Don't worry about "protecting your source code" - even the proof to Fermat's last theorem was published; nothing is *that* sacred. To insist that it is just makes you look self-important."

Funny thing is that I actually agree with this statement

The issue for me is that I have a lot of of financial experience so say if you wanted a routine to calculate the internal rate of return for an array of cash flows, bingo, I've got it straight away. I can implement this routine in minutes, but for a newbie, he's standing there with his thumb in his mouth saying "whats an internal rate of return?".

Should I just say - "here you go, here's my routine that I wrote years ago probably at another employer and it probably took me hours, but I give it to you whom I have never met free of charge"?

Or a complete record concurrency class that I slot into every application that I write.

Or libraries to populate grids. etc, most of you will get the drift, solid failsafe stuff that you've used for years that works 100%. It's not really IP but its working code that achieves what would take days or hours to develop in minutes if you know how to use it.

When I develop software myself I usually build to my spec and then strip out all the stuff that the application doesn't use, then of course I leave the code behind, the client owns it and can do whatever they want with it.

Maybe I'm just peeved that I'm not doing the software build (writing the code testing etc call it whatever you want)
100% myself and I just don't play in the sandpit well.

Realist
Tuesday, April 29, 2003

What it gets down to is that the employer sees that it's more convenient - for them - to have their internal staffer do your job.

However this is not more convenient for you and, given that your expertise has been acquired over many years and at cost to you, you are entitled to have your own interests represented.

The Real Realist
Tuesday, April 29, 2003

It's absurd to talk of the nobility of montorship in regards to a company whose top developer has 2 years of experience and they have to bring in advanced developers on contract. The juinor developer guy this company will fire as soon as convenient. The idea of mentorship and helping others works great in an environment with job stability. Without that environment, it's everyman for himself and charge as much as you can. Companies don't look out for their employees. there are no guarantees. It's a rat race. This is fine, no problem. But only an idiot would give away trade secrets for free in such an environment. Have I been mentored or taught? Sure, I paid $50,000 in tuition and expenses for the privledge of being mentored in classrooms with 200-800 other students. One on one mentorship I can only imagine would be vastly more expensive.

Bell Labs had mentorship once upon a time. They were able to because they bothered to keep senior developeqrs with experience around long enough for mentorship to be possible.

You won't be doing any one any favors by giving this company your secrets for free while they try to squirrel out of the development agreement you had and bring in cheap labor. I assume you gave them an hourly combo rate based on the understanding you would do both the design and the development start to finish. Now that you've done the expensive design work requiring a higher rate normally, they want to save money by suddenly bringing in this guy to do the coding and factoring out your pay. Forget that. If they want you to help him, they have to pay you both to compensate you for the money on the total work you were expecting, and for the economic value of the secrets lost. You also have to worry about this new guy quitting his job and moving into your territory with your own trade secrets and competing with you at a lower rate.

Ed the Millwright
Tuesday, April 29, 2003

What I'm trying to say is if they were offering you a stable, long term position with pay reflective of your experience and special knowledge with a golden parachute clause, THEN you can feel safe and happy giving away secrets and mentoring the next generation.

Without that, if they want mentoring tell them to send their employees to your weekend seminars at $6500 a pop, minimum enrollment 15.

Ed the Millwright
Tuesday, April 29, 2003

Of course, it's easy to be enthusiastic about "mentoring" your direct competitors if you don't know much anyway, and you're not very good at teaching.

If you're good and have valuable background, it's just giving away money.

The way to handle it, as others have suggested, is to charge extra for providing your pre-existing, valuable code, and charge extra for providing training courses.

Also, for training, that's really a big task if it's done well. It shouldn't be mixed with serious development.


Tuesday, April 29, 2003

Realist - absolutely you should offer it to him. He'll find it somewhere else if he looks, anyway.

The talent is not in creating the libraries; the talent is in understanding how to use them. I'll bet that a lot of the time you're in those libraries tweaking them for the current use; either he's talented and will be able to do the same, or else he's not and if the library doesn't fit the problem like a jigsaw puzzle piece, he'll spend a month just trying to figure out why.

If you're lucky, you'll be able to document that month and use it to show the managers *why* you charge so much, and that you're actually cheaper in the long run. :-)

Philo

Philo
Wednesday, April 30, 2003

Just want to say that as a customer I would never work with any consulting companies if I could not own the source code. I may license  some libraries or components if they are really worthy, but I would try to have access to the code.

Anyway, if it's not part ot the contract, negotiate!

Rick Tang
Thursday, May 01, 2003

Rick do you make use of any Microsoft software or libraries? How do you go about getting the code to those - I'd like to have it myself but they are being stubborn. Should I refuse to use MS stuff and  stick to the competitor? Speaking of which, what about when the competitor's source-accesible component doesn't have the same quality as that of the source-secret component? Go with the lower quality and remain pure or do you never find yourself in that position?

Dennis Atkins
Thursday, May 01, 2003

There's a large difference between working with a consulting company and buying COTS software.

RocketJeff
Thursday, May 01, 2003

*  Recent Topics

*  Fog Creek Home