There’s no such thing as a fixed price software development project

Fixed price software development contracts are a bad idea because they fail to limit the customer’s costs and they worsen the quality of what is delivered. In this article I will explain why.

What makes software development hard is that a group of people must clarify exactly what they want a computer to do in many thousands of situations. Between a senior executive having an idea in the shower one morning and a computer executing that idea, many people will be involved. Each person might have a different interpretation of that idea and every conversation about that idea might introduce mutations to that idea. Modern software development methodologies have evolved to help groups of people move towards agreement on how software should work by introducing techniques to specify how it will work. These include functional specification techniques (User Stories, UML), visual specification techniques (UI and UX design), iterative specification techniques (Agile processes), and formalised specification techniques (Test Driven Development).

Those techniques are all useful, but a piece of software is never fully specified until it’s been written. The developer takes these artefacts and makes the final set of decisions about what the computer should do. We can tell this is true because it is often necessary to ask a developer “What will the software do in this situation that we’ve just thought of?”. The developer will then check the code to find out.

Any software development project is therefore a collaborative exercise in deciding what should happen in each situation and writing that into code. This is what makes software development hard, not the ability to write code per say. Over years many attempts have been made to make coding easier by making the syntax more like English. But while languages like ADA, COBOL, Python and Ruby made coding more accessible, they didn’t make software development projects significantly easier, because they didn’t change the fundamental nature of the problem.

During a fixed price software development contract, any individuals on the supply side of the commercial relationship have a strong incentive to influence the decision making in favour of simplifying the software, to make it easier to write and test. The people on the customer side, on the other hand, have an incentive to remove manual tasks for their employees or make their customers’ lives better. They will try and influence the behaviour of the software in that direction. Sooner or later there will be a disagreement about what the software should do. The supplier will say that the behaviour being discussed was not made clear at the start of the project and they want to re-negotiate the price. The customer will respond that any reasonable reading of what was specified at the outset should include the behaviour being discussed and that the price should not change.

Although the supplier on a fixed price software project many not succeed in renegotiating the price every time they want to, they will succeed some of the time. And when they do they will take the opportunity to make up failed attempts to renegotiate the price earlier on. Ultimately, the customer engaged the supplier because they need them to build their software for them, and they will not be able to resist every attempt to renegotiate the price. So they will be forced to pay what the supplier says they need in order to complete the project. In very rare circumstances the customer may cancel the contract, but this is costly for the customer and just starts the whole project again, albeit with a new supplier.

Does that mean that customers should request fixed price contracts anyway? On the basis that it might work, but if it doesn’t they’re no worse off than if they had accepted a time and materials contract? The answer is no, because having two camps in an adversarial battle over how the software should work does not make for good quality software. Sometimes these battles are conducted in good natured discussions. Sometimes they are passive aggressive moves by the supplier to quietly implement their interpretation and see if a bug is raised, and sometimes there are full blown arguments with both sides threatening to call in lawyers. However it’s conducted, it’s not helpful. Good quality software comes from everyone involved being focused on the goal of making the user’s life easier.

In summary, no software development project is ever be fixed price because the scope is not defined until the code already exists, and having some of the team trying to avoid making the users’ lives easier does not make for good software.