Fog Creek Software
Discussion Board

Compulsory support role for departed programmer?

Well, my initial challenge with the "abandoned project" client has passed, and I have an assurance of getting paid just as the sun rises... God, I feel like a loan shark sans the baseball bat...


The situation this company has in hand was caused by their one D....i programmer bailing for personal reasons. Nothing was written down. The build instructions this person provided to me on request are gobbledegook. My client knows and groks and accepts my take that the initial task of getting a build in place is unknowable until it's done.

My conjecture:

Would there be any legally binding way (in the US, anyway) for a company to bind an employee to provide up to X hours of support, contractually, after their official termination, at a stated minimum rate?

Example of such a clause: "Employee agrees that, after he leaves the employ of XYZ, that he will provide, on request and at the expense of XYZ, up to 30 hours of phone, email, or in-person support on a contractual basic, to be paid at a rate no less than $70 per hour, plus travel and associated expenses, within a 120 day period. Employee further agrees that failure to comply as possible with such a request for reasons other than personal injury, military service, or other compulsory legal entanglement, is reason for judgement for liquidated damages."

Or something like that.

The company I'm working with is hurting big time. Likely the job may not have been a plum - or, the person himself may have created a mess and just wanted to walk away from it and start afresh.

But the economic damage that one employee who bails can cause appears to be boundless; and could go as far as putting the previous employer out of business.  In this instance, the code is broken, unbuildable, it's locked up in the mind of a person who won't talk. And my understanding is that this person simply doesn't give a shit whether he gets paid or not.

Anyone ever see any successful attempt to mitigate this risk other than throwing $100s of $K at the programmer?

Regardless of the means by which a company tries to avoid or mitigate such a risk, it's a very interesting philosophic problem. Can you force someone to do the "responsible" thing?

Bored Bystander
Saturday, August 28, 2004

I've used clauses similar to that in several employment agreements, but without a prenegotiated agreement there's nothing to compel anyone to do anything in a right to work state.  Most employers reserve separation agreements for executive level positions.

Proving negligence in a civil case is difficult and the employee can easily turn it around and argue that the employer was negligent by not documenting and enforcing acceptable work standards (in this case coding standards, source control, build scripts, automated testing, etc.)

On the other hand, civil suits are frequently filed to compel people to negotiate and withdrawn once an agreement is reached.

Saturday, August 28, 2004

The company didn't have this guy document his build process or document any of his code. And that failure can possibly cause the failure of the entire company.

Simple - this company deserves to fail.

Also, if anyone gave me a contract with a "Compulsory support role for departed programmer", I would immediately walk out - contract unsigned.

Saturday, August 28, 2004

>> The company didn't have this guy document his build process or document any of his code. And that failure can possibly cause the failure of the entire company.

>> Simple - this company deserves to fail.

Er, *cough* *cough*.... ahem... dum dah dee dah dum...

I'll feign nonchalance. Just wanted to get the contrarian reaction. :-)

Bored Bystander
Saturday, August 28, 2004

`Regardless of the means by which a company tries to avoid or mitigate such a risk, it's a very interesting philosophic problem. Can you force someone to do the "responsible" thing?'

I'm curious why it is the "responsible thing" for a departed employee to provide this sort of role?

Dennis Forbes
Saturday, August 28, 2004


By "responsible thing" I mean that if a former employee would allow themselves to be contracted for a limited number of hours to provide post-exit transition, then it may (for instance) prevent their former employer from (potentially) closing shop and laying people off, just because the employer misses a few important pieces of information.

A broader view, now.

Many times a programmer is hired as an ordinary, non partner employee, to produce a necessary segment of a product. The programmer may be bringing more or less "commodity" skills to the table but nevertheless, in a small company, has control of a disproportionately large amount of "leverage". IE: a run of the mill employee who eventually becomes irreplaceable just by position and opportunity. 

As far as the employer's duty to enforce process: what if the programmer is the only programmer on staff? Or the employer asked the programmer employee to help them develop an initial offering and the employee said
"yes" and staggered through it? And then bailed because the coffee in the office was bitter one day.

I guess what I am saying is that, while it appears to competent programmers in a community of peers (such as this board) that lack of process, lack of source control, etc, are solely the responsibility of the employer -

I am saying that if the employee in a given disclipline is a singularity in that role, doesn't that employee have a moral duty to not bring the house down by providing some triflinging small amounts of support? At least to ensure that their previous employer is covered.

I'm not particularly attached to any particular solution or remedy. I am just posing this question as an ethical strawman.

I would, in this thread, like to omit the obvious scenario of "bastard abusive low rent employer who got theirs", because it's just too easy to justify a skip-out. Also I would prefer to omit the involuntary termination - layoff or firing - in that instance, the employer should know that all bets are off.

Bored Bystander
Saturday, August 28, 2004

Addition to my post:

The situation I am posing is an "HR version" of all eggs in one basket. The basket is lost; so should the employer be screwed because they put all their eggs in one basket?

Bored Bystander
Saturday, August 28, 2004

Well yes that's the problem with keeping all of your eggs in one basket.  I mean come on, part of good (or even fair) project management is reducing your "truck factor".  And really the higher your "truck factor" the more you can count on the truck coming by.

When an employee leaves under "normal circumstances" there usually is an offboarding process where knowledge transfer / documentation and all of that other stuff that mitigates the situation you describe.  And I suspect that said employee will be glad to answer a few calls and or emails with out charging.  I can recall one former co-worker (and actually then returned but now former once again) that came in over a weekend to help with an application deploy that went south.  Responsible people don't screw folks that treat them fairly.

In  the situation you describe I begin to suspect that even if you could compel the former developer to help you probably wouldn't want the help you got.  Something happened there to cause the situation you find yourself cleaning up.  It was obvious from your previous post that it was pretty bad - that's why you were wondering if you should take it or not.

Lastly I suspect that the vast majority of clauses like the one you propose would be nearly unenforceable. And the only time you really would need to enforce them you will find that court battles would drag out the time to a point that once the help became available it would be too late to save the company that was careless enough to keep all of their eggs in one basket.

Saturday, August 28, 2004

Good comments, K.

Dragging my thinking back to conceptual models such as "The E-Myth" - good business management dictates that a management should *NEVER* put itself in the position of relying upon irreplaceable and/or unknowable resources that are central to its business.

A good business wouldn't allow one employee to control an essential aspect of its business.

In that light, there is no need for my proposed "clause" and my clause is not defensible on any level except protection of clueless companies from their own blindness or arrogance.


Bored Bystander
Saturday, August 28, 2004

Programmers are interchangeable bricks. Just get another one and have him complete the bricklaying. If the OP can't fix it on his own then he must not be a very good bricklayer.

Saturday, August 28, 2004


You're making yourself look good by slamming the previous guy.

This is not productive or helpful for any parties. Reason is the previous guy is not to blame - this situation is entirely the employers fault.

1 - Previous worker is so pissed off at company he will give no useful advise and refuses to come in even for $70/hr and all expenses paid. Does this suggest he experienced a respectful and supportive work environment when he worked there?

2 - In attempting to hire Bored, employer tries to negotiate on price by saying he could get an Indian who can do the same work for less money. But strangely, he hires the more expensive Bored! Does this suggest that he understands development issues, respects workers, and is an honest negotiator?

3 - Bored has so much problems with even wondering if he will get paid that there is a gigantic thread discussing this issue until Bored has the balls to insist he be paid. Is a work environment in which someone even has to thing about posting such questions a good one?

I would never sign such a dumb clause because you never know what sort of assholes you might end up working for. It is critical you be able to leave and never return or even think of the abuse you suffered.

It's obvious that the employer is a jackass and incompetant as well. Now, it's fine for you to take the job and try to straighten out his stupidity, even though it will be a futile endeavor.

But, given the situation as you've stated it, it's totally unfair to blame the previous guy and your proposal that he sign a slave contract is frankly, sickening.

I think you are suffering from Stockholm Syndrome. You are sympathizing with the agenda of your abusers.

Worker Bea
Saturday, August 28, 2004

Bored, slavery went out in the 1860's. If the employer wants something, they need to pay for it to be done. It's very very simple.

If they can't afford to do that, they don't deserve to be in business. They should get out of the way so successful businesses can take their place.

Me And The View Out The Window
Sunday, August 29, 2004

The 'responsible' thing would be for this guy with 'commodity skills' to chip in a small amount of work to bail out his former employer?  Oh yeah, he'll be paid market rates this time?  I'm uncomfortable with the clues to this story.

Maybe this guy had endured months of being dissatisfied with your company? Maybe he had to quit and find another job, with all the hassles that come with that?  No doubt he is not in the mood for a few billable hours.  Unfortunately it has come to this.  If his knowledge is really worth that much to the company, cut a deal and pay this guy to make your problems go away. Even if he is simply being irresponsible, the company managed this guy wrong. 

Sunday, August 29, 2004

The later posters are reading a lot more into my descriptions than what was meant.

No, I'm not defending the client. My belief is that *everything* is screwed up for a reason and when someone is left holding the bag, I wonder why that someone is in that position.

I have no idea what the previous developer's story is.

No, I'm not serious about my employment contract proposal. It's simply a talking point. I see a problem caused by relying on one person for a unique role in a company; I wondered if there were a procedural remedy. So I posted an attempt at one.

See my comment earlier about "good" general business strategy. Only an screwed company would make someone who is not a principle almost indispensable.

And as far as my dealing with them, see the remark about my feeling like a loan shark. I have imposed order on the deal in order to ensure that I get paid for a best professional effort. I was ready to walk w/o a certain guarantee (OK, it's prepayment.) They understand that they've inherited a mess.

My guess is that the (techie/consulting scientist) owner denigrated software in his mind, assuming that programming was a 'mere' secretarial effort. Nobody there wanted to know what was truly involved. Until the person quit.

Bored Bystander
Sunday, August 29, 2004

> Only an screwed company would make someone who is not a principle almost indispensable.

I like this. May I turn it into a pair of axioms?

A.  A dumb company makes someone who is not a principle indispensable.
B. A smart company makes someone who is indispensable a principle.

So many companies go down the drain when they forget B.

Worker Bea
Sunday, August 29, 2004

To get ourselves back on track:

"Would there be any legally binding way (in the US, anyway) for a company to bind an employee to provide up to X hours of support, contractually, after their official termination, at a stated minimum rate?"

The answer is yes, assuming each party agrees to said terms.

Of course, thankfully, this is America, and there is no way anyone can be *compelled* to give said support after termination.

Simply put, make sure to have a lawyer look at the employment contract.  You will need to be very careful regarding at-will status and you will need to be very careful about clarifying what the conditions of employment will actually be.

Good luck, you've got more of a stomach for this than I would.

Sunday, August 29, 2004

BB, you could take this opportunity to set the client up with a source control box and a build environment. It won't take a lot of effort to pitch it as "so this won't happen again." The discussion you seem to be having with the client is that they are afraid they will get left in the lurch again. Why not sit down and think about what it will take to keep it from happening again? That way, handcuffs are not needed.

I dunno... Ant and CVS for an open source enviroment. Make a well documented write up for the client.  You know better than I, which SC product works best with the language you are using. I have very little experience using borland dev environments.

Help the client eliminate "bus factor" or "truck factor" or what ever you want to call it. Good risk management will try to mitigate the possibility that a key employee will get run over by a bus/truck, or quit and join a rock band. Every time I try to add "bus factor" to a risk plan, it gets removed because folks don't want to think about it, therefore it isn't allowed to be planned for.

This guy has been rained on, why not sell him umbrellas?

Sunday, August 29, 2004

If the programmer was central to the business, why wasn't be being paid or recognised for his value? Why this idea that he must do whatever the employer needs done?

It is clearly a stupid employer. Let him go out of business and our programmer can then get that same business.

Me And The View Out The Window
Sunday, August 29, 2004

The suggestion is clearly impractical and unfair for an employee; in the case of an independent contractor paid for goods and services provided that is a different matter.

If the employer knows about it to start with, then he should make it unnecessary by insisting on full documentation all the time.

And if he doesn't know about it to start with, then he's not going to think of putting it in the contract.

There is a notice period. The employer should have insisted that all of that time be spent on providing documentation.

Stephen Jones
Sunday, August 29, 2004

Actually contract terms which extend responsibilities beyond the life of the contract aren't enforceable.  All one party would have to do is say the contract term was accepted under duress.

If the other side tried to sue on the basis of it what damages could be extracted?  None.

You can't compel someone to work for you. 

Simon Lucy
Sunday, August 29, 2004

Oh I guess there is an exception to that, trust can be considered to be enforceable after the contract has ended.

Simon Lucy
Sunday, August 29, 2004


You work with some of the most worthless clients in the entire world.  Where do you find these jokers and why do you work with them?

Sunday, August 29, 2004

How about this:

Blutto Bubba Jones, referred to as EMPLOYEE, being employed for the critical function of stacking boxes, agrees to stack 1000 (one thousand) boxes for EMPLOYER within 30 (thirty) days of termination of employment.

Look, when someone quits, they've quit. Original poster's potential client deserves problems if they don't have documented build procedures in place.

. dot .
Sunday, August 29, 2004

It's not clear to me that having the departed programmer back for a while would really help. He didn't do his job right when he was there before, what's to stop him from reading JOS all day if he's forced to come back?

Sunday, August 29, 2004

>> Where do you find these jokers and why do you work with them?

Time for some education, Muppet.

It's CONSULTING, dude. They have a problem that seriously impacts their business. I am fixing it for them.

A client has run out of options and needs a professional fireman to bail them out. I'm it.

The challenge in working in these situations is to educate and (to some extent) control the client's perceptions (with facts) so that they understand that 1) they are up shit's creek, 2) they need you, and 3) they must pay you on your terms in order to produce a result necessary to their business.

And - human nature time - EVERYONE who has a deeply ingrained problem of their own making - whether it's an alcoholic, or a company that has no process - is in denial and needs to be told that it's no longer business as usual.

The thing is: every business isn't going to have nice servers and good, professional technical co-workers, and configuration control over their source code, and a professional attitude toward the work.

The companies that do these things have turned software dev into a reproducible factory operation (as it should be) and aren't dependent on only one prima donna. These are the companies that many of you guys think "everyone SHOULD work at". In reality, these are the places that stroke geek egos, which geeks fight to get into.

Those other nameless businesses that rely upon software but which have disregarded and downplayed its complexities (at the technical, project, and lifecycle levels) are fodder for a consultant.

Bored Bystander
Sunday, August 29, 2004

"I am saying that if the employee in a given disclipline is a singularity in that role, doesn't that employee have a moral duty to not bring the house down by providing some triflinging small amounts of support? At least to ensure that their previous employer is covered."


A single employee shouldn't be asked to consider the long-term fate of the business as part of a contractual or ethical consideration, unless he's being paid to do so (as with a principal).  I think that's the whole idea behind professional management.

As soon as you impose legal or ethical requirements on the employee to "keep the lights on," the burden of liability (legal or otherwise) shifts disproportionately to the employee.

Let's consider your clause--I know you aren't serious about it, but again, just as a talking point.  It stipulates that the employee provide a certain level of support with the obvious end of keeping the business going.

Well, let's say the employee does what's required and, nonetheless, the business still goes under.  The business owners, who have no real technical knowledge or detailed knowledge of what he did, are in a great position to sue him for breach of contract.  The damages being, of course, the lost revenue that brought down the business.

He'd win, you might argue--but not before he had to fight it out in court ($$$$).

The same position can be taken for "ethical" responsibility.  Maybe the employee does what he can, and the business goes under, and then he's "blacklisted."

Honestly, I think the point that's being glossed over here is that technical people are not treated as "key" to the business's success, and are not incentivized to stay.  Company policy should be to aggressively promote the interests of employees who "drive" the technical end.  That's just common sense.  And I don't think either documentation or process can really make up for the code-ownership of original developers.

There are just too many microscopic points of knowledge in a product for a developer to document them all and, when he leaves, the business is basically paying to have them rediscovered.  Usually at the customer's expense.

No company would ever dream of simply firing its CEO or letting him leave in mid-execution of a grand business plan that only he knows.  Hence golden parachutes.  Why is the sole owner of a company's _technical_ vision nothing but a shithead with a computer?

Sunday, August 29, 2004

>doesn't that employee have a moral duty to not bring the house down by providing some triflinging small amounts of support? At least to ensure that their previous employer is covered.

The sensation you are feeling is guilt, not "moral duty."

Jack Welch (CEO of GE) said a stunning whopper that will be repeated until the end of time by businesses: "you got paid on friday, now we are even."

Sunday, August 29, 2004

how about this scenario:

employee reformats hard drive on last day at job. including some essential bits of something which weren't properly backed up.

since they were paid, everyone's even, right? a full backup of everything should always have been running.

that's the basic issue when you work in a field which is driven by 'intellectual property': it can be stored in someone's head, even if it 'belongs' to the company. how do you get back what you (the employeer) paid for?

Sunday, August 29, 2004

Everyone seems to be missing that, attached to my proposed employment rider, I proposed contract payment to the departed employee, pegged at or above expected market pay in that type of job, as compensation for their trouble. Also, exemptions for reasons of dire personal or legal circumstance. And it has a time limit. (I didn't even think of a COLA rider but that's certainly doable too.)

Nothing free, unpaid or otherwise Dickensian about it. In fact if I drafted such an agreement I would include language that the ex-employee could choose their mode of contact: email, phone or fax.

The crowd here sometimes reminds me of /. , jumping to a kneejerk predictable conclusion w/o reading everything.

Another tact might be to put in writing a post separation bonus payable only upon the employee's cooperation with such a process, if such a process became necessary.

If I ran an ISV I'd probably consider some employee agreement boilerplate along these lines. Not because I would want to run a purposefully shitty company with no process but because I would be trying to contain unforseen business risks.  Such as the employee who walked away with (say) a password to an encrypted volume that contained their recent source code.

Bored Bystander
Sunday, August 29, 2004

mb, you have exactly the right idea.

Bored Bystander
Sunday, August 29, 2004


Your comments are thought provoking... Where you are going with your commentary is that a developer 'ought' to be treated similarly to an executive and that includes acknowledgement that they hold a portion of the company's 'wealth' in their head. Which itself (I think this is your direction on this) merits their treatment essentially as a professional.

My take on this is symmetric in some ways. I implicitly acknowledge this type of role in my original postings here.

But I pose the assertion that sometimes (or often) the level of employee who may enjoy such "leverage" over their employer may have paid no dues nor suffered through necessary aspects of the business, such as sales or business development that preceded coding, and which even made the coding job possible. They were hired, they simply did their 8x5x52 job, and they became absolutely indispensable in the process of working a normal 5 day a week job.

IE, a scenario (NOT the client in hand, just a hypothetical):

A couple of business people in mid career partner and start an ISV named Big Idea, Inc., based upon an idea about a market that they have spent many years in, in marketing, customer support, or sales roles. They remortgage their houses, they raffle little Tommy's iron lung at the pawn shop, etc., they take out business loans to finance their dream. 

So, they need a programmer. They recruit at a local college. They find one. It's the standard "go through hell and grow with us and be top dog one day" spiel.

Joe Coder joins them. Initially  there are no company profits, he is paid out of pocket.

He spends several productive years there. Is new to development. Has no mentoring. Puts spit and chewing gum together. Works miracles. Does so on a 40 to 50 hour a week schedule maybe the occasional Saturday. No travel, gets to see his girlfriend, gets paid vacations. Is on market level salary plus small bonus.

Profits grow. Company hires people for sales and marketing. The original owners respect Joe's contributions and give him decent raises and don't encumber him with a lot of management.  He SEEMS self managing, after all, he produces and doesn't break a sweat.

One day the inevitable headhunter comes a'callin and entices Joe to leave for greener pastures.

Joe is told the balloon is going up. MUST start next Monday, no way the client can use him any later.

Joe bolts.

Big Idea, Inc. is thrown into chaos:

- All technical work is frozen.
- The owners feel betrayed because they gave Joe his start.
- The owner's asses are on the line.
- The owners purposefully did NOT hire a "supervisor" to breath down Joe's neck and flog him to obey an abstract process because they trusted Joe and they expected that Joe would leave things in a reproducible state.
- Joe has no time for support for his first employer.
- Big Idea, Inc. has its first layoff.
- Big Idea defaults on its credit lines, and is forced into Chapter 11 because it has no time to react.

I know the following view isn't very popular on this board:

You aren't God just because you can program.
You aren't God just because you can produce something useful for someone.
The coder/developer may have gotten work because someone else sweated the inevitable dues paying before him, and so he effortlessly (almost) glided into a position that was premade for 'any' developer.

The amount of leverage that one programmer can have over a smaller company seems asymmetric, almost in the same way that a couple  of terrorists can kill a lot of people by "careful" planning.

But everyone can't be a principle or an executive.

It's a conundrum. I just proposed a non fascistic way of dealing with it.

Bored Bystander
Sunday, August 29, 2004

>> merits their treatment essentially as a professional.

change to

>> merits their treatment essentially as an executive.

Bored Bystander
Sunday, August 29, 2004

what it comes down to, Bored, is that said programmer essentially *is* the product development effort.  That, in and of itself, may have a huge value regardless of the items you mention.

Simply put it is the responsibility of the principals to mitigate their product development effort against disaster in any way possible. There is no excuse or reason that justifies letting your product walk out the door!

The easiest, and most sensible method to accomplish this is to spread the product development across a team, and make *damned sure* someone in a stakeholder role has accountability for that team.

This is just common sense software engineering.

Sunday, August 29, 2004


Its a very interesting scenario, and I'm sure there are some out there which inherit many of the properties of yours.

A few things:

Usually, an employee gives a 2 weeks' notice.  This is customary, though not always required.  What should a small employer do during these 2 weeks?  Get a contractor in ASAP to learn what Joe has been doing for the last 5 years.  Brain dump, code walk-through.  2 weeks of solid explanation.  Most employees give a 2 weeks' notice.

What did your prospective get?  Any weeks' notice?  What did they do with them?

Now here is a cute little twist:  A small employer decides that it will not compensate employees for unused vacation.  Joe gives his 2 weeks notice, and says hey, y'know what, you guys won't be compensating me for those 2 weeks of unused vacation.  If I show up at all during this time period, it will be a friggin' miracle.

I mean there are so many variations on this theme.

Anyway, most companies have without cause agreements that employees sign.  Which state that we can fire you without cause and you can leave without cause.  They are usually signed by the employee, not the employer (what about that?) and are meant as a way to get rid of the dead wood (oh, if only they would) without hassle.

Every company (now 8) I have worked for, I signed a version of a "without cause" agreement.  You know what we tell engineers to do when they get laid off, fired, or are underemployed: "gow up", move on, get on with it, etc.


Sunday, August 29, 2004

I don't really see the problem here.  Programmers shouldn't be forced to contract away their ability to make more money elsewhere.  If the company  can't afford to pay the programmer what he is worth, the programmer should be free to go to another company.  If the programmer is vital to the success of the comany, then he should be paid accordingly or made a co-owner of the business. 

Sunday, August 29, 2004

It's an interesting business and ethical dilemma, any way you slice it.

And today I have definitively proven....

Not a damned thing. <g>

Bored Bystander
Sunday, August 29, 2004

Look, if this was a lawyer's forum, you wouldn't see this whining crap about how the guy walked away without finishing the job.

You would see discussion about how much you could charge the company to do their work, because they have a big need.

There is nothing wrong here with the programmer's behaviour. There is plenty wrong with the acceptance that he's done something wrong.

Sunday, August 29, 2004


Your scenario strikes a nerve with me because I'm in a similar position.  As a developer, that is.  I am basically in the situation of having a ton of leverage because I "own" a product that the business depends on.

In my case I work for an established-but-small software company that otherwise has processes and documentation, and so in that respect it's much different.  Our executives really don't have much excuse for letting me become a well of core-competence.  Furthermore I wouldn't classify the application or my skills as "generic," although that's probably my hubris speaking.  :)

So I've been debating how to handle this, and what the implications are (or should be) for me professionally.

I agree that not everyone should be a principal.  I certainly think the money should go to those who put in the risk and the sweat equity.

But on the flip side, there is a lot of pressure and risk that an individual programmer endures in the "product ownership" situation versus, say, working anywhere else.  That is to say, for the same market rate that's paid to others, a programmer in this situation has the added pressure of direct revenue accountability.

Implicitly, a programmer who works on such products is part of a sales process that is often high-stakes.  He must work closely with the businesspeople to ensure that product demos work smoothly and meet the expectations of clients.  And if a product bombs in front of a big client, that can be all-she-wrote.  That's to say nothing of the shoestring working conditions, or the petty tyranny that management usually displays.

Because of the reasons you've stated, I don't think a programmer deserves to be an executive with an equity stake purely for such contributions.  But to persevere on such a project merits some kind of "quid pro quo"; otherwise, why bother staying around?  There are plenty of big companies that are hiring competent programmers for the cube-dwelling, propellerhead positions.

In short:  people join small companies for the opportunity to have a high impact, and for advancement as the business grows.  And when that isn't present, it gets frustrating, _really_ quickly.  Especially in pseudo-entrepreneurial roles that require continual, "above and beyond" ownership.  Some companies do hire JoeSchmoeBeerKeg out of college for these major projects; that is beyond naive.

So my input is:  I'd only be willing to accept such a contract, and its associated liabilities, for higher pay and some guarantees about professional development (eg leadership-track).  I think the stick requires a carrot--and I don't think the payment you stipulated is enough, because it's not fully considering the professional circumstances that led to the departure.

Finally, I'd like to add that this thread reminds me of the "survivor mentality" you've talked about before.  That is, the propensity of developers' careers to be nothing more than a series of myriad projects and war stories.

Definitely there's a reason for that.  Developers take ownership of technical direction for a company, bring it up to speed on a shoestring budget, and then because the executives don't have the technical wherewithall to recognize their contributions, are unwilling to promote them professionally.

So, being developers, the reaction is simply to passively-aggressively quit.  Wash, rinse, repeat.

Sunday, August 29, 2004

If someone wants to make that last part to be made into a "motivational poster",  I'd pay money for that.

Sunday, August 29, 2004


Great observations as usual.

I do want to distinguish between the lot of employees and my own situation. I was asked by this company to help on a contract basis. After endless negotiation over the contract realities, I said "enough" and now I'm working on a prepayment basis. And I said that a condition of my working on it is that they accept that it's rife with unknowns until I say otherwise; the only deliverable until stated otherwise is hours.

Yeah, the subsistence stature of programming as an occupation compared  to the impact you can have on a small company's standing is apalling. That subject itself deserves its own thread.

Bored Bystander
Sunday, August 29, 2004

>The owners feel betrayed because they gave Joe his start.
Everytime I quit a company, they felt betrayed. "giving Joe a start" is just an excuse, Joe could have had 1,000 years exp in the profession, walk on water, have written 800 programming languages, and his boss will always feel betrayed when Joe quits. That is human nature. Live with it or get out of business.

Also, a major complaint is that companies don't hire folks to give them a start. A recent Wall Street Journal article was complaining about the shortage of "swiss-type" machinists. That type of machining has a roughly 10 year apprenticeship. No companies are willing to hire apprentices, they want the already experienced workers, and when those workers retire, or won't come back after a layoff, the companies go whining to the newspapers and politicians for more h1b visas. We've seen the same sort of whining in the press about pseudoshortages of nursing, engineering and programming professionals.

The vast majority of companies are not going to allow an ex-employee access of any kind. In the past 25 years, I only worked for one that did it, and they were too cheap to hire a replacement (oh, peter, we moved to a new building, here is a key and a code to the alarm). 

>employee reformats hard drive on last day at job. including some essential bits of something which weren't properly backed up.
When you give your notice at most companies, are fired or laid off, they walk you to the door, right then. They don't let you back at your desk because some folks do exactly what you mentioned. I've never met someone who did that, and the industry is small enough that if you did such a thing, word would get around and you would never work for anyone again. One company I worked for informs its employees and contractors that they have been laid off when their access cards no longer let them into the building.

>The amount of leverage that one programmer can have over a smaller company seems asymmetric, almost in the same way that a couple  of terrorists can kill a lot of people by "careful" planning.
I've seen more companies sunk by corrupt or incompetant accountants than by "ungrateful" employees that jump ship. You would sing a different tune when you see an embezzling accountant put 36 people out of work because he "needed the money, but now he is really sorry." It is a real ugly situation.

And hoser has a good point. If your employee gives notice, take every minute of that time to get everything written down. Most employees will give 2 weeks notice. Most companies give 0 notice. That asymmetry is going to shrink, and no one has the right to complain about it.

There is a reason that banks and other financial companies force everyone to take a 4 week vacation each year. It prevents things like "leaving with the password to the encrypted volume with the latest source code" from happening. Perhaps you might like to have some lunches with some folks who work at a big bank about how they handle stuff like this. Why are you trying to reinvent the wheel?

Sunday, August 29, 2004

"If your employee gives notice, take every minute of that time to get everything written down"

I just want to know, though--and I don't necessarily disagree with you--write down what?

"On line 270 of foo.cpp, there's a nasty bug when ..."

The value that a company really loses when someone leaves is that intuition from having one's thoughts simmered in a codebase for many months.

Build processes are indeed worth documenting (and automating), but they are the jagged tip of a very deep iceberg, as knowledge goes.

This is something that I find amazing in general about this industry--the lack of appreciation for "micro-knowledge" about code.

When Joel talks about avoiding rewrites because the miniscule bits of value--bug fixes and what not, that make code "ugly"--are lost, he has a great point.  And it applies in the case of losing employees, too.  You lose historical and intuitive knowledge about those microscopic, line-by-line elements that give code its real value.

Just as a digression, think about the implications that has for large-scale "knowledge transfers"; e.g. offshoring and outsourcing.

Monday, August 30, 2004

Wow Bored,

You said that a programmer who leaves for greener pastures is "almost the same" as a terrorist who kills innocent civilians.

I'd say that means you are trolling and this whole thread is bogus.

At least, I hope it is because it would sicken me to think you are being serious with this stuff.

Dennis Atkins
Monday, August 30, 2004

You mention the case of Joe Programmer. He single handledly creates teh entire product line from scratch. There is no one else creating product. The fate of the company lies on his shoulders, therefore he CAN NOT MUST NOT leave or he is 'almost the same' as a 'terrorist'.

Ideas are a dime a dozen, the founders ideas are worth NOTHING. Implementation is EVERYTHING.

Now the financing they brought and marketing, that's worth something, but not the idea.

Joe did not lock up the source code or take it with him, he merely left. They need to hire anothercoder and have him finish the code.

If the code contains so many innovations that a new coder can not do so, then maybe it was a mistake not to make Joe a principle.

You keep talking about these supposed 9-5 nothing unskilled people upon whose shoulders lay the fate of the company.

That is impossible. If unskilled, hire an interchangable part to replace them. If otherwise, then maybe they should be treated as professionals instead.

Dennis Atkins
Monday, August 30, 2004

Any executive in a company that lives and dies by research and development needs to understand the basics of the field they are working in. A company that finds itself doomed when a single, allegedly unskilled person leaves, OBVIOUSLY does not understand the field they are in and should not be in that field to begin with. Them going bankrupt is a blessing to the free market.

Are you involved in product development? You need a risk analysis and a risk management plan. If you don't have one, you don't know what you are doing and deserve to fail. Plain and simple.

Lot's of talk about the incompetant programmers not deserving jobs. What about incompetant managers? Why exactly DO they deserve to be employed? Isn't going bankrupt the best thing that can happen so they can get the WalMart jobs they are qualified for and free up their salaries to develop REAL products?

Dennis Atkins
Monday, August 30, 2004

>> You said that a programmer who leaves for greener pastures is "almost the same" as a terrorist who kills innocent civilians.

I used a lousy way to connect the two ideas together. What I was trying to state was the assymmetrically large impact that one person can have on a company.

>> I'd say that means you are trolling and this whole thread is bogus.

Nice try.

Bored Bystander
Monday, August 30, 2004

Bored, no contract is going to help if the ‘irreplaceable’ person has the nerve to just up and die.  It happens, you know.  When people die they don’t usually give 2 weeks notice. And they are not available to come back and help no matter what the contract says.

“What if Joe dies?” is a useful perspective to think about. It allows you to think about real ways to deal with the problem (too much dependence on one person) rather than thinking this can be solved with the right employment contract wording.

Monday, August 30, 2004

>> The value that a company really loses when someone leaves is that intuition from having one's thoughts simmered in a codebase for many months.

I think the group concensus here pretty much governs this issue in general. A lousy company will not treat knowledge like this as strategic.

Indeed, the company in question treated the development I am describing like a blue collar rote task. Evidence: the C++ guy there was both dismissive about "trivial mere UIs" and didn't appear to aknowledge that a build (a first order effort, as you said) would require any effort. And the company started out looking for a fill-in contractor as a commodity buy.

I've had the chance to look at the old programmer's work. Creating a build is a challenge because the code is so large and is divided into many DLLs and packages.

My guess is that an inexperienced person at their first programming job hacked the system together, got burnt out on the complexity they'd created, and wasn't allowed to refactor. So they quit. The code looks too multi-level, too many classes and source files for what the app does. A standard "green programmer going nuts with too much code" behavior. Again, lack of oversight from the employer.

I'm also finding a couple of third party libraries that are three version levels behind the language version being used. So the company didn't want to pay a few hundred bucks for updated libraries. That's telling me something right there...

Bored Bystander
Monday, August 30, 2004

I was this programmer once.

I worked at this place and there were 7 in my department. Before I left there were 2 and this was in the heyday and we were being reduced. It was disheartening.

There came a day when they decided to bring me in at the beginning of anything that had an inkling of technical. It turned out that I sold the first client. A HUGE client.

No one cared how I did what I did. No one paid much attention.

As I was building the app for the HUGE client I needed some design work. Not much, maybe about 5 hours time maximum. The designers were too busy to help me. My direct boss was a decent designer so I asked him to help. Too busy. I then sent an email to the whole company about my plight. I was given a talking to but I got my 5 hours of design time.

App launched on time. Client was thrilled. During this time I had mentioned that we needed more than just me. I could not do everything and do everything at the same time. The client wanted to evolve the app, great, more money. The client also had another project they wanted us to build. The company was not going to invite me to this. Without even asking my opinion the hired someone who would be me at such meetings. This person was a nice person but they were a moron. The client demanded my presence.

Anyhow, you can imagine that I was not a happy camper. The person they hired took my role on another project that I had also helped sell (and design) and he subsequently turned it into mush.  I began seeking another place to work.

Well I got another job. I felt duty bound not to my company but to the clients I had sold so I tried to document as much as I could before I left(never had anything documented before). I also told my new "boss" that I should vet any programmers he brought in. This guy never did that. I spoke to him years later and he said he thought my request made no sense.  Well, there you go.

About 5 months into my new job I get a call from my client at HUGE client. It was too funny. She said the company said they could not contact me, they did not know where I was etc. etc. and lo and behold she found me. She said the company was giving her the runaround about  a problem and I outlined a solution to her which she then told them to implement (such a minor thing it was hard to believe it was a problem).  A year after I left this HUGE client discontinued any technical relations with the company. The company became a ghost of what it had once been.

You are so quick to blame the orginal programmer. Don't believe all the hype. Never read code and begin with "what crap is this" ... you just never know the circumstances.

At one time I believed that programmer's work could be commoditized but the more I live the less I believe this to be true. 

Monday, August 30, 2004

Dear 'me',

I remember. I was there. Glad things are going better for you, T.

Monday, August 30, 2004

>> You are so quick to blame the orginal programmer. Don't believe all the hype. Never read code and begin with "what crap is this" ... you just never know the circumstances.

Me, I'm not blaming the original programmer.

My theory: anyone will take the easy money, anytime and anywhere. It's a given of human nature. When they don't take the easy money, SOMETHING is wrong. So if you've developed a series of applications at the same company and you move into maintenance, your life becomes fairly predictable and easy.

So, this person whose pieces I am picking up quit an "easy" job that they had learned - easy for that person, that is.

So, my thinking goes, the job was probably a lot harder and/or less satisfying than it would seem to have been. The money wasn't worth it.

My guesses: the work was interrupt driven and become very frustrating; the employer wouldn't tolerate any beneficial process; the employee was never given due credit; tools sucked; the job was underpaid relative to the frustrations; etc. Probably a combination of these factors.

I do think that someone in such a job has a duty to push back on stupidity. Some programmers are absolute wusses and will never bat for themselves. But I have also been in the middle of circumstances where pushing back is a one way ticket out the door.

Basically, I'm pretty open minded. I'm ready to blame anyone who seems deserving.  :-)

Bored Bystander
Monday, August 30, 2004

*  Recent Topics

*  Fog Creek Home