In the early days of the software industry, attorneys assumed that they could comprehensively capture
a business relationship in the written contract. The agreement would include detailed specifications for the product to be developed, and there would be a project timeline with milestones tied to achieving those specifications. When the agreement was executed, usually after many months of negotiations, the parties knew exactly what they were contractually obligated to deliver and when. Even then, this was a myth.
If we required a detailed, final specification for development before the parties could begin work today, we would only be assured that the results would be too late to market to be valuable. Agreements today have to be focused on establishing the process for working together to develop something which neither party can fully define or envision. In other words, the only thing we know is that what we develop together will change as the work is performed, the operating environment is updated, and the market changes.
Thus, requiring that a fixed list of the specific software components that will be used in the development be included in the agreement may not make sense to the people who will actually perform the work. They may know that the list will change often, and they do not want to amend the agreement every time they consider, include, or replace a component. A process acceptable to both parties that allows for the rapid evolution of the work to be performed will be welcomed.
Software will change continuously over the course of its normal life.
Software is never “finished” until it is uninstalled. Constant updating is required to accommodate changes in the operating environment and to apply patches that become available to eliminate potential security vulnerabilities. If the software is not updated, that should be a sign that necessary software maintenance is not occurring. And changes in the hardware or software operating environment provide opportunities to improve software functionality. The agreement should not be written based on the assumption that all development will come to a conclusion at any point prior to the end of the life of the software.