3 ms·

> By far the most costly defects in software creation are due to incorrect requirements or poor systems design. I'm willing to bet those can be fixed with math

> By far the most costly defects in software creation are due to incorrect requirements or poor systems design. I'm willing to bet those can be fixed with math. By formalizing the requirement, you're bound to spot any inconsistency, and probably even some other kinds of errors. Same with systems design. "Small is better" and "low coupling is better" for instance, can be formalised and measured. By the way, you can't escape the fact that ultimately, the final program is supposed to be a formalization of the requirements. Inevitably, the messy ideas in the brain of the customer are bound to be reduced to math. Better use simple math as early as possible, so you can easily check them against the requirements. (Of course it won't happen because most people either won't be able to see the math behind the requirements, or won't bother).

InclinedPlane 15y ago
That implies that you can specify all requirements in a mathematical form, which is not the case. How do you specify a usability requirement? Software is for humans, that makes it messy, even down to the requirements level.
- loup-vaillant 15y ago
  > That implies that you can specify all requirements in a mathematical form, which is not the case. I concede that requirement themselves can't be completely reduced to math. But most of them can. Also, the system itself (excluding human operators) can definitely be reduced to pure math. What I was proposing was to check the pure math specification against the mostly math requirements. If such math are simple enough, it should be easy enough to make sure the specs match the needs.