The problem with putting specifications in the contract is that developing the specifications is a large part of the effort!
Compare to construction – what most contract software developers do, is much more akin to what an architect does for a house, than what a carpenter does. Sure, there is also a bunch of carpentry that needs doing, but software development is less physical and can re-use more components than a typical building project, so, percentage wise, the time spent in requirements and specification development is much larger for software than for construction.
The process could really be split in three:
- Parameter definition – this is a high-level consulting engagement, figuring out what could be done at approximate cost and technology levels. Call this 2-10% of the work.
- Specification development – this is a time-and-expenses design engagement, where the actual definition of the product can be made and built, to the point where it’s possible for a buyer to say “I want this!” and for an implementer to say “I can build this!” Call this 30-70% of the work.
- Actual implementation – People push buttons to make computers do things, and out comes code you can run. While various interesting bugs will happen, and surprise technical limitations may occur, assuming pieces 1 and 2 were done right, the risk of error here is much less. Call this 20-68% of the work.
Now, back in the good-old-days when IBM sold you computer systems, they’d swallow #1 as business development, and they’d engage in a consulting project to do #2, and finally end up with #3, and once the real code was written, reality would mean that the customer frequently wouldn’t fully solve the problem they thought they were solving, but IBM doesn’t care – they just bill you as per contract. This might be a fine outcome for IBM, at the time, but not so much for the customer. This is the waterfall model, and legal contract frameworks exist to address each step of the way. It’s also a terrible match for modern software development.
Because many of the requirements are unknown and unknowable until you have something that works to poke at in reality, a much more cost effective way is to iterate through these three steps in some kind of circle or spiral. The idea of “agile” software development comes from this realization, and the idea of “prototype discovery” and (in games,) “vertical slice” all take root in trying to crack this nut.
A good engagement will then be structured as “let’s start small, do a simple thing, poke at it, and see where that goes, with potential contract extensions for any additional requirements discovered.” That model has, in general, worked much better overall for me. The main draw-back is that unsophisticated buyers don’t understand why it’s important, and don’t have the stomach for the significant uncertainty involved in even understanding where the finish line might be located, much less what it would take to get there.