If requirements volatility is the core problem, the next question to ask is, Why is this the core problem here and not in other engineering disciplines? I thin

If requirements volatility is the core problem, the next question to ask is, Why is this the core problem here and not in other engineering disciplines? I think it stems from a mismatch between the perceived cost and the actual cost of changing software, which one of the first comments on the article captured: > That’s my take – the perception that software is simple to change, which stems from the lack of understanding of its inherent complexity by users, and the fact that it is, up to a certain point – is what makes requirements volatile. Part of the problem too is that the actual cost of changing software varies by an order of magnitude or more, depending on how fluent the developer is with the tools they’re using, and how good they are at accommodating change. If that’s not something even we as a profession (if you can call it that) have been able to reliably quantify, expecting a client to understand it is beyond the pale. I’ve been programming for most of my life, so if I see an app then most of the time I can get a sense for how long it’d take to build. But I still have this nagging feeling that building software — the act of translating what’s in your head into working code — seems to take way longer than it ought to.