These systems are in one sense ideal for formal methods: they're complex interactions between systems, often coordinating over resources and time, with many easily identified constraints that must be maintained.
On the other hand, they're awful for formal methods to the tune of how expensive and valuable it is to actually get a complete description of what the intended behavior of these systems even is.
The bane of application of formal methods in software is that many practical automated systems are only intended to perform against an incomplete, often somewhat inconsistent, and often rapidly changing goal specification. They could be leveraged very fruitfully against these problems, but to do so would invite a long, expensive requirements gathering process between modelers and business owners. There's some anecdotal evidence that this is a valuable process, but the economics don't work out. Even in circumstances where the benefit is obviously there, formal methods front load cost and thus increase delivery risk in many projects.
I think the right way of bringing these techniques to practical software is through expansion "horseback formal methods": lightweight semi-formal tooling and practice which pays out moderate value for moderate investment. These techniques could be run earlier on in a project and demonstrate the value of formal methods while reducing the eventual cost of implementing the heavy hitting tools later on.
A lot of software engineers practice this already, but don't always have the experience to connect back-of-the-envelope domain modeling to mathematical modeling. Or don't find it sufficiently valuable, which is fair. Hopefully, expansion of popularity in these methods will increase the popularity of making smoother transitions from lightweight modeling to more expensive, formal, comprehensive modeling.
Agreed on lightweight formal methods. TLA+ and Alloy have been really eye opening to use, and it's almost at no cost. They're just tools for expressing logic and analyzing models.
Even those are very heavyweight to my mind. I’m thinking things as simple as applying semantics to flow charts and making state tables. Exhaustive enumeration of small spaces forms a neat on-ramp to more powerful methods, if we choose to treat them that way.
Here "horseback" is a term I'm using to mean "applied in the field, cutting corners as needed to make things valuable now". I'm not sure exactly where I picked it up, but I like the idea.
On the other hand, they're awful for formal methods to the tune of how expensive and valuable it is to actually get a complete description of what the intended behavior of these systems even is.
The bane of application of formal methods in software is that many practical automated systems are only intended to perform against an incomplete, often somewhat inconsistent, and often rapidly changing goal specification. They could be leveraged very fruitfully against these problems, but to do so would invite a long, expensive requirements gathering process between modelers and business owners. There's some anecdotal evidence that this is a valuable process, but the economics don't work out. Even in circumstances where the benefit is obviously there, formal methods front load cost and thus increase delivery risk in many projects.
I think the right way of bringing these techniques to practical software is through expansion "horseback formal methods": lightweight semi-formal tooling and practice which pays out moderate value for moderate investment. These techniques could be run earlier on in a project and demonstrate the value of formal methods while reducing the eventual cost of implementing the heavy hitting tools later on.
A lot of software engineers practice this already, but don't always have the experience to connect back-of-the-envelope domain modeling to mathematical modeling. Or don't find it sufficiently valuable, which is fair. Hopefully, expansion of popularity in these methods will increase the popularity of making smoother transitions from lightweight modeling to more expensive, formal, comprehensive modeling.