Why I don't give fixed price. Software developer story.
December 24, 2007 – 01:49Recently I’ve chatted with a potential customer.
He seeks developers to create a simple social network application. He spent some time doing this. Actually, a considerable time and a sizable budget: one year and a half and undisclosed amount of money.
Now he’s got three different implementations of his idea. All three partially working. All three not ready for a production use. Two out of three developers broke their (extended) deadlines and he stopped to work with them. The leader of third group is not returning calls as deadline approaches.
It smelled like a typical deathmarch project for me from the very first words exchanges with current developer. Being there, done that, know what to do to get out of the deathmarch hell.
Despite I’m charging considerably more that his current developers, he seemed interested in me: I have project management experience, I speak like I know what to do, I can start right soon and can get more developers into the team.
Nevertheless we’ve not contracted.
The show stopped when I was asked to provide an estimate for the project.
My opinion is that asking for an estimate at the engagement to the software contract is suboptimal, at least. I can’t provide a project “estimate” if I’ve not spent time reformatting the specs to my standard, read the code, tried it and documented the defects, outlined the plan, estimated it, experimentally verified the first step estimate and corrected it. Just because “the estimate” in the software development is what other people call “the bid”.
What I can provide at start is a guesstimate – here we have N functions, M screens, so it should take kM + lM days.
But just when I append the usual disclaimer that this number should not be relied upon in any kind of financial and time planning, the understanding breaks.
Actually, what customer desires is just a fixed price bid, so he can get rid of financial risk.
Game of bidding
The bid selection on software project is too much influenced by the bid bottom line.
It would be a good thing, if it would include any kind of total cost analysis with some model attached. But what bid on a small software project does this?
At most, it includes a detailed analysis of cost drivers and a total development budget. And in most cases it just states the amount of money paid to developer upon project completion.
Nevertheless, the development budget is the easiest thing to understand in the bid. It’s just a number.
No wonder the bid is mostly selected by the budget. No wonder developers learn the game very fast – underbid and get the project. Whatever happens next.
Parameter space of the software project
It is an established custom to treat a software project within 3d parameter space:
- budget,
- delivery time,
- quality.
If the project has fixed complexity the volume, occupied by the project in that space, presumably, stays constant.
But…
Where’s the project complexity is fixed? There’s no such thing like a perfect information transfer between two persons. There are always errors in understanding. The project requirements, unless specified in a strict semantics (like programming language 
) are always subject to an interpretation.
Therefore the actual best estimate of the volume, project occupies in the parameter space, will always change with time.
That’s the reason why any project plan should allow room for errors and resources to fix them.
Logically, next question from a customer would be: why I can’t pay an insurance against such errors? Finally, it’s the developer who’s the specialist? Why can’t he include that in the price?
Simple probabilistic model of a feature development.
Of course, a developer can do that. If he has the level of discipline, comparable to the traders of financial products (e.g. options).
Most developers don’t.
The pricing of options, err.. feature estimation is counterintuitive. And even the best financial models tend to underestimate the effect of the “long tail”, the effect of events with little probability.
Let’s build a simple probabilistic model of single feature development.
Let the complexity of feature would be 8 points. That means, it would require 8 hours of constant attention of the qualified and prepared developer, without any interruptions or problems.
Of course, that won’t translate into 8 billable hours. It could be anything from zero to infinity with a peak near 8. Good developers will have sharp peak, mediocre – wide one.
Also, say, it would take about a clock day to complete. With the same probability distribution.
Next, someone had to review the feature. Name it code review, acceptance testing, anything. Let it require 1 point of complexity and require another a day of clock time to complete.
The review has 4 chances to accept the feature to production and 1 chance to return it to development.
(Gamma distribution on all values, alpha = 2, beta = number of complexity points or number of days)
What would be 95%-level certainty estimate for the implementation of this feature to take?
41 billable hours and about 9 days to complete!
What would be 50%-level certainty estimate? 16 billable hours, 4 days to complete.
How that compares to blind estimation of 8 + 1 hours? Where is the intuition there?
The fallacy of risk minimization
A rational developer, equipped with such model, would give estimated 41 billable hour and ask for a 9 business days timeframe to complete the task.
So what the “rational” customer desiring to minimize his budget risk would pay? He has quite good changes (45%) to pay 25 hours less (41h – 16h) and get his result sooner by a work week.
Then why the hell I’d advise my customer to overpay me? Why would I put myself in ridicule position of explaining how “a day worth work” translated into more than a work-week fixed price bid? Or why I would underbid and increase my own risks?
I would welcome any analysis of the simple model above to show that I’m wrong.
The recursive nature of estimation of software project.
See how the development of a simple “day-worth” feature translated to complex “inflated” estimation?
But the actual software project is much more complex than a set of such features. Features get dumped, added, misunderstood and, finally, even some bugs slip review and (OMG!) go onto production. This all adds another loop of confusion and complexity and inflates a reliable bid even more.
Yet customers require fixed price bid even before the detailed planning is done. What a developer ought to do? Refuse to bid a fixed price, bear the risks or play “this time will be different” game?
The way out.
The software development is a superposition of several complex probabilistic processes. An attempt to put a fixed price tag onto it would be similar to put a fixed price on an financial instrument. An attempt to establish a “fair” price on goods based on careful analysis. History teaches that no one learns their lesson latest huge attempt to do this failed miserably.
Financial market has its own solution – the trading, which establishes what is believed a fair price.
And it’s time to recall that the goal of a software development is not to establish a “fair” price for a project. The goal is to develop a product.
An attempt to minimize risks by obvious means finally costs much more for a customer than the risk itself. The obvious means are not rational.
An attempt to minimize risk in a software project is similar to an attempt to calculate an outcome of tennis match from the names of players and the brand of rackets. Do really any rational tennis player try to set the game plan ahead?
No, of course. They do the work in tight iterations. Watch-move-swing-hit-watch-move… etc They minimize risk by close coupling of facts observed (moving ball) and their own movements.
In software development the analogy would be tight development iterations. Promote enhanced versions to production weekly. Release on staging daily. Do a continuous integration builds to watch the code integrity after each build.
And if you are overbudget, make a business decision to stop or to allocate more funds. That’s not a development problem.
Cease overplanning. Get a life.
PS
Ah, yes, my customer, I’ve started with…
Yes, you know his story already. He was blinded by estimations he was given and his desire to minimize the risk. His product is in the development from early 2006 and is not yet complete. What he tries now is to get “more reliable estimates”, preferably from “more experienced developers”. Let the force be with him.
