Fog Creek Software
Discussion Board

"Rescue abandoned project" contract - opinions?

Hi -

I posted a resume on a web site some months ago and a small out of state company contacted me from the posting.

I have expertise in a certain dying niche language (that begins with a D and ends with an I). The company makes a series of scientific applications, it's owned by a consulting scientist, and they had exactly one D...I developer who recently bailed on them in an abrupt manner. 

The company has "critical" business needs to move forward with their products, but nobody there knows how to even build an application in this language nor make minor modifications. They basically contacted me to do this for them.

Some red flags:

The initial contact was handled as a commodity buy. They told me that the owner was comparing me and others to offshore people in the single digit rate range. I scoffed and just said "fine". They contacted some of my references and decided that I was it.

The first contract I got from them was completely one sided in their favor (example, they wanted me to legally indemnify them from errors in my work). It took 2 weeks of haggling to arrive at a reasonably fair contract.

Most damning - right now I am in possession of a pile of source code and I am told that the previous developer is unavailable for any questions beyond asking for locations of source files. (I was literally told to not contact the person about anything except file names.)

I have found in the past that even when the situation is not quite this adverse, rescuing abandoned code is a miserable, thankless job. The preconditions that accompany this project make it just about impossible to predict success or plan the project.

I have already raised their attention to these issues with a very detailed report. They seem to think they've addressed the issues but what I have still doesn't build and is "mysterious". It's a pretty large project - several hundred K lines of D...I code with no docs, not under any source code control. So I've informed them what the scope of the problem is.

This is hourly T&M work. My intuition is that most clients will not pay on invoices that aren't accompanied by evidence of solid progress.

These people are basically giving me a "software treasure hunt". I can see, for instance, working and invoicing them for several dozen hours and still not having something completely ready for prime time. Most clients in this "end userish" a position won't pay for something they can't see working.

High risk == no deal. I'm thinking of telling them to find someone else.

What does anyone else say here?

Bored Bystander
Friday, August 27, 2004

High Risk Client + High Risk Project = No Go

Friday, August 27, 2004

Bored, with something like that I would tell them to expect me to spend a few weeks just learning the existing codebase. Nothing else.

I would explain they won't see anything at all during that time, but when development does start, the resulting application will be clean and reliable.

If they've got brains, they say: "OK." If they don't, you really have to make it clear what the conditions are. If they don't accept, tell them about India.

Management material
Friday, August 27, 2004

That is, tell them to make other arrangements.

Management material
Friday, August 27, 2004

Facing something along the same lines:

Politically-charged client
Project management keeping us from interactign with them
Specs changing at the last minute
Impossible deadline

... and the software will be late. We told them so and they keep saying "it will be on time" to the client ...

It gets on my nerves... Almost ready to do a write off.

High Risk Client : YES
High Risk Project : YES

I should have known better...

Friday, August 27, 2004

I'd tell them to fuck off, unless you really need the money.

And I mean literally tell them to fuck off.

And die.

Mr. Fancypants
Friday, August 27, 2004

Almost any project is recoverable given sufficient time.  And that's the sticking point; some projects require near infinity to save. :)

Do they have an idea of what they consider to be a reasonable time frame and/or have you given them a timeline?

Friday, August 27, 2004

Do what most people do when they are giving private tuition. Charge up front.

Stephen Jones
Friday, August 27, 2004

> My intuition is that most clients will not pay on invoices that aren't accompanied by evidence of solid progress.

Getting it to build would be the first step (first milestone of success). Until that happens, the "evidence of progress" is your timesheet that describes what you've done towards that goal.

The possibility of their not paying is a separate problem. Work-arounds might include payment in advance; or your "fronting" them for only small amounts, e.g. "I want to be paid at the end of each day of work".

Christopher Wells
Friday, August 27, 2004

Ask them to hire more programmers and build a team at first (of course , you are the team leader!)

then give them a list of bugs to prove that most modules need to be re-written.

if no bug found, write some automated-test script to make bugs.

Write the daily-build script

Donot forget to tell them they are lucky because ONLY you can build the team, ONLY you know how to design, automated-test case, and ONLY you can write daily-build script!

At last, you can imply to your boss that,  IN THE FUTUREN, if all those routines done by YOU, even one off-shore team can maintain the product. So it is important to invest on you NOW.

At worst, maybe you can get some management experience.

If no team, say bye

Friday, August 27, 2004

Dying niche language, pah !

I have some experience in this area. I've refactored end-user applications and refactored badly managed software that was written by so-called professionals.

This is an utterly thankless job. My instinct is that your customer has no idea what proper software development actually is. I got burned by a very reputable finance organisation when in got in the middle of an abandoned software development.

As it's a small company, you may be able to redeem the situation by educating your customer.  Get together a briefing about why they are in a mess based on common errors in the software development process (no docs, no source control, one-brain-to-rule-them-all, no oversight, no reviews, no standards, etc) and make sure that you back yourself up with reputable examples from the literature or ideally the internet so they can go straight there and see that you aren't making it up. Emphasise that a structured approach will cost them less than their chaotic mess, and make more money.

Software-illiterate managers, especially engineers and scientists, are crushingly naive about writing software. The most common errors are that they think it's a perfectly deterministic process (sob) and because they have no understanding of decomposition, etc (wail) they cannot understand why M$ can deliver something the size of office, but their unplanned, unevolved, 'just-add-this-bit-here' codebase chokes after a couple of releases: you must just want more money.

Personally, I love these projects because I love teaching idiots how not to be idiots or, if necessary, blowing out hardcore idiots. Nothing, more satisfying, is there, than  from the swamp, hmm, raising a professional software outfit. Hmm ?

If they don't buy the re-education, walk. 

Friday, August 27, 2004

If you are turning down other work for this then by all means walk. Otherwise I suggest you sit down with them and talk about the issues you've posted about.

Friday, August 27, 2004

Don't let the Delphi nerds find out you consider it a dying niche language. :-)

Friday, August 27, 2004

If they need you more than you need them, you may be able to negotiate a retainer for the work.

That way you can be certain you'll be paid for at least a week/month/whatever.

Normal practice when law firms take on new/risky clients after all...

Friday, August 27, 2004

"I have found in the past that even when the situation is not quite this adverse, rescuing abandoned code is a miserable, thankless job"
    rate = rate * 100

Friday, August 27, 2004

If the code doesn't compile AS IS, wha makes you think it actually *CAN* compile?

Get paid for your analysis if you can, but pass on it.

Friday, August 27, 2004

The fact that you even WROTE this post means you already know that taking this project on would be a bad idea.

If you like, I will put on my Mr. Authority Figure hat (I think I have it here somewhere) and give you official permission to avoid touching this one with somebody else's ten foot pole.

Devon Grey
Friday, August 27, 2004

"Don't let the Delphi nerds find out you consider it a dying niche language. :-)"

Too late. We're fast. We've already emptied his bank accounts and had a new highway re-routed through his house.


Friday, August 27, 2004

i would tell them exactly what you want. ex. establish source control, etc.

if those demands aren't meet and i mean immediately (before more pasta making) then i would tell them bye.

Friday, August 27, 2004

I've had some assignments where I had to pick up the pieces left behind by the *big named consultant*. Folks at that company thought that I had to be incompetant, because the BNC was so highly recommended that he needed a wheelbarrow to transport his balls.

Milestone 1: getting it to compile (sometimes includes obtaining the development tools, and one client was too cheap to even get those).
Milestone 2: finding out that it never worked.
Milestone 3: proving to the client that what you have was never compiled, never ran and could not possibly work as is.
Milestone 4: building replacement out of salvagable pieces and new pieces and getting it to work.
Milestone 5: dodging the VPs who want blood because BNC cost $20k+ for something that looked pretty, but did zero.

They can be challenging, sometimes fun, usually will push you past your limits.

Anyone looking for commodity pricing and indemnity for custom development is someone to avoid.

I agree with the above posters who have identified this as both High Risk client and High Risk project. You should know how much risk you can live with.

Friday, August 27, 2004

Stephen Jones has a good point -- while you probably can't get any money out of them up front, you probably should bill them weekly, with the expectation that they FedEx you a check by the next Wednesday.  No check, work stops.

Friday, August 27, 2004

It's a high risk project so you can ask for serious money in exchange. Unless you *really* believe there's someone in India who can do the project, you're probably dealing with a bluff. They are probably desperate. You aren't.

If they are serious, then this should be acceptable:

1. Get rid of their contract and send them a simple letter aggreement (that your lawyer has reviewed).

2. In the letter carefully stipulate that the engagement is T&M and be specific about payment terms (keep them on a short leash - you own everything you do for them until paid for, etc.).

3. Get a substantial retainer up front. Offer to escrow it with you attorney at your cost.

4. Approach the project in phases. Every phase has a clear cut deliverable and comes with an estimate based on what you learned in the previous phase.

(I.e.; Phase I - discovery. Establish baseline for source code, usability, known bugs, etc. Deliverable is a document and recommendations for moving forward to address priority issues as defined by management. Include cost estimates for next recommended phases. Give them a couple of cost/deliverable options.)

If they won't go for the professional approach, walk away and don't look back.

I've had the misfortune of batting cleanup under similar circumstances before. It's can get very ugly very fast so you have to set boundaries right away.

Good luck.


Friday, August 27, 2004

Greetings, my fellow Joel pros.

While I've already made my mind up about this client (high risk, unrealistic, and yes, definitely, naive scientist type expecting deterministic results from a broken process) I just wanted to validate what I was seeing before cutting the client loose.

This has been an exceptionally shitty year for me for billings. However, What I really don't need at this point is work on a project that doesn't pay because the client doesn't have their act together.

The suggestion that makes most sense in terms of risk management is to ask for a retainer. I'll do that before terminating, unless they go first.

Thanks, all.

Bored Bystander
Friday, August 27, 2004

"...ask for a retainer"

not sure what your teeth have to do with all this...

Friday, August 27, 2004

I was actually waiting for that comment. :-)

Bored Bystander
Friday, August 27, 2004

That's why I keep coming here: "Biting humor"

(You asked for it. So there!)


Friday, August 27, 2004

imho, "from scratch" trumps salvaging not-compiling (=> never tested => nary a bugfree piece. qed) cant-talk-with-originator code, most days of the week. (tuesedays i sometimes get high).
i know its off-topic, really, so regard it as a footnote.

naive bystander
Friday, August 27, 2004


Admittedly it's crap work (maintenance) and redevelopment would be preferable. This place has only budgeted a few thousand for this work, though, so I don't see there being much flex.

Bored Bystander
Friday, August 27, 2004

There may actually be some benefit to letting them flounder for a while.  If the project MUST go forward, let someone else (in india?) demonstrate how hard this is.

I WOULD point out the problems and how you'd fix them.

They won't believe the problems now, but after the above happens, they may realize you were right.

That gets into lots of EGO issues; they don't want to admit you were right, etc. be gentle :-)

Mr. Analogy {Shrinkwrap ISV Owner}
Friday, August 27, 2004

professional scapegoat = rate x 3

Friday, August 27, 2004

If they've only budgeted a few thousand, you need a new contract and short payment cycles.  Tom's suggestion of short phases sounds the best to me.

Clay Dowling
Sunday, August 29, 2004

If the project merely involved busted code, a low budget, and an ignorant client, you could deal with this professionally: Fix the code, work in small stages, and educate the client.

Unfortunately, there are several serious danger signs here: The unprofessional, one-sided contract; the weird instructions regarding contact with the previous developer (*no* contact would be understandable); and your intuition regarding payment.

I'm not adverse to resue work--I've cleaned up some truly foul codebases--but this is trouble. If you have the option, just walk away. Some people just don't deserve custom software.

If you have no choice but to work on this project, get paid frequently (and start preparing the documentation for the court case on day one).

J. Random Hacker
Tuesday, August 31, 2004

*  Recent Topics

*  Fog Creek Home