The article talks about the one contract that had the requirements fixed -- but then fails to talk about how contracts should be laid out to embrace changing re

The article talks about the one contract that had the requirements fixed -- but then fails to talk about how contracts should be laid out to embrace changing requirements. People have known for a long time that volatile requirements are a core problem, but that typically hasn't really affected the way software and software development services are procured. This might be different in other parts of the world, but my impression is that even custom development contracts are procured the same way that you would a big shipment of physical goods, which is just insane. Once you work as a developer in a project that was procured in such a way, it's already too late. The knowledge that requirements will change and will totally disrupt your development process is there, and it doesn't really help you.