Title: How to Talk Oneself Out of a Job

In this (true) tale, all the names have been changed to ensure innocence.

One morning a few weeks ago, I received a telephone call from John Dawes. John is an old colleague, but I hadn't heard from him for ages. He said that he had been commissioned by a client of his to find someone, or some company, who could do a piece of programming; would I be interested? John would not tell me who the client was, or indeed what they did, except that the work would involve parsing a language called Extracode, a language with which I was fairly familiar, and passing the results to an their internal database. He also said that they wanted to a first release of the code in about five months time, although the contract would not be given for over a month, leaving less than four months of development and test. I agreed to look at a specification if he could provide one, although I pointed out that although I was familiar with Extracode, I had not had occasion to write a parser for it.

I contacted Nigel who is the one person whom I knew would be capable of doing this work but is tied by a serious non-compete clause with his current employer. We discussed what this project might involve and were in agreement that 6-9 months was a reasonable estimate for the work without more detailed information. Writing the BNF is straightforward, although tedious, but getting the semantics of the language right takes time. There are a number of features that are really quite obscure, and some of these are not defined accurately in the standard, only by reference to existing implementations.

So a few days later the spec arrived. It was not a long spec, but gave a good indication of which parts of the language were needed, and that this project was to provide a front-end from Extracode to their internal database. It gave the features (by chapter number in the standard) in the order in which they were to be implemented, with a review half way through when a prototype should be available. At the end of the spec they stated: "This contract covers both Extracode and ESL. It is estimated that an ESL frontend would require a similar amount of effort again to implement as the original Extracode". ESL is another language designed to do similar things to Extracode; I have some experience of it, but not as much as with Extracode.

Alarm bells have started ringing. My original estimate of the project was 6-9 months, which would not meet the client's delivery expectations, and now they want to double it (on their estimate, not mine!) although I am fairly certain that they do not expect ESL within the original 4 month delivery date. I think that ESL is rather harder than Extracode, I do not know anyone who is more experienced in it, and the spec for this part of the project is even lighter than that for Extracode. Looks like this might tie me up fairly well full time for two years. If the client wants this to be a fixed-price contract (as John originally implied) then they can forget it. I am not even sure now that I want the Extracode part, let alone the ESL half. I might, however, be able to recover the situation if I can find some existing code that does most of what is required. Hello Google!

Searching the Internet revealed that there are two commercial offerings which will provide most of the functionality required. These from are Integrated Software Corp (ISC) and Vertical Solutions Inc (VSI). Both these purport to support Extracode and ESL, producing a common data structure. There is also an open source project called Pegasus Extracode which, although implementing Extracode only, might be sufficient to get things started and we can sort out the ESL later. I can't find any suitable open-source ESL compilers. I contact ISC and VSI and download the Pegasus source code to give it a go.

I speak first to a representative from ISC. He is very helpful and says that they have a product that seems to be a perfect match for the requirements. He gives me their pricing policy - somewhere in the region of $100K p.a. plus $5K p.a. per customer. He asks whether this is within budget, and I have to admit that I have no idea. I do not even know who the client is, let alone how much they are willing to spend. I will pass on the information and let him know when I have anything more to say.

Next comes VSI. They have a different way of operating - they supply the full source code to all customers, and want payment either as a lump sum or in installments. They trust their customers not to use the software if they don't pay. However the payments are made, they need to earn $350,000 over three years, and they will also take 15% for maintenance (which is required in order to keep up with changes in the standards). Therefore the pricing of the two commercial products looks about the same if the product is to be used in-house, but if it is to be sold, then as little as 20 customers doubles the price of the ISC offering.

I compile Pegasus and run it. It works after a fashion. However, there are fundamental features that are not implemented, like include files. This makes this option much less attractive. It is covered by the GPL, so the client would have to ensure that the front-end would write a text file, or have some other means of disconnecting it from the rest of their (proprietary) code in order to be able to give away the source when they sell the software. There appears to be a fair amount of work here, possibly not much less than starting from scratch, but what we do get is free.

I send off an email to John. It says much as I have done in the last few paragraphs, i.e. I do not want this contract as it stands; I do not think that the Extracode part will be done in time; I am not confident about the ESL part at all, and certainly not in the terms written; the client should look at ISC, VSI and possibly (if money is really tight) Pegasus. I expect John to say thanks, but no thanks. He doesn't. A few days later he rings to say that the client (whom he now identifies as a start-up called Excellarate) is really happy with what I have said and that they would like to meet. Oh, and by the way, you know one of them. I do? Oh yes, you were working with them years ago, and Mike Fish is looking forward to meeting you again. I was in a collaboration project with Mike over ten years ago, when John was in the same company as me, but John never met Mike a that time. Ah well, small world; laughs all round. Excellarate already use ISC and are unhappy with them (mainly, I think, because of that customer licence price), so are trying to find an alternative. They had not encountered VSI before.

So off I go on a train to meet John, Mike and someone I haven't met before, Alan, who is the director of engineering at Excellarate. They introduce their technology, I tell them about my experience - John and Mike know some of this, but it is all new to Alan. I then say (again) the thoughts that I had on this project. ISC is a good match - well spotted - so we quickly pass on to VSI. After a brief discussion of the other options it is clear that they are quite taken with VSI (and indeed this is what I am suggesting as the best option). Since VSI does most of what ISC already does, and so only the calls into their database need coding, is there anything left for me to do? Well, to be honest, no. Either they could get VSI to learn their interface and write custom code, or Excellarate could learn the VSI classes and write the interface themselves. Getting me to learn both the VSI and Excellarate systems seems like a complete waste of time.

They have half a dozen other bidders for this project and there is a meeting in a couple of weeks to determine the preferred option, so I am off to enjoy my holidays and will find out the results when I get back.

Back from holiday and I contact John to find out the situation. Excellarate were very impressed with me, and were delighted that I found VSI (they can't work out why they did not find VSI themselves) and the decision, still to be finally ratified by the board, is to use VSI and write the customised code in-house. That gives them their project easily on time, and gets ESL incorporated too. No work for me, and just as importantly, no work for the other bidders. John says that he put forward other individuals like me, small companies and some large multinationals so that Excellarate had a really good choice. It seems that the others stuck to the spec, and produced plans accordingly, and some of these bids were extremely expensive (maybe they didn't want the work either). I was the only one who took out the "how" of the spec and looked for the "what", to find an alternative solution.

So, I talked myself out of a job. Did I achieve anything? I think so. I showed Excellarate that doing it all themselves is not necessarily the best solution. I did not overload myself with work that I did not particularly want, and probably could not have dealt with anyway. And I earned some Brownie points: Excellarate has put me on their list of approved contractors. Doing nothing is sometimes far more satisfying than embarking on a large project. It is completed more quickly and is, of course, the ultimate in bug-free software :-)