> On the contrary, you may find that you are shipping software that is so good you begin to see the value. You may also find that when you finally do ship, eve

> On the contrary, you may find that you are shipping software that is so good you begin to see the value. You may also find that when you finally do ship, everyone had started using your competitor, or that your customers needed something slightly different, or that the cost of waiting for you was so high it would have been better having something early. I have great respect for formal verified software, I have even touched on it a bit during my PhD, and there are definitely places for where it makes sense. Same for formal methods in general. But there are other software tasks where it is not just 'not needed' but it is actually the wrong choice. It depends a lot on the opportunity cost of delivering later, and on how well defined the tasks are, and how preffesional the customer is. And the tasks where less formal methods are the right way are not "playing games", they are solving the problem under a different set of constrains, also doing software engineering.