Why have formal methods failed to breakthrough on the market for such a long time?

Main -> FAQ -> G-HM-2


 * Theme: General Information on FM (G)
 * Role: HM

Answer
Following the rapid growth of computer science, exaggerated claims about formal methods might have been made in the past by proponents of formal methods. Such claim might have hindered the credibility of the proponents, and the formal methods themselves. For instance, consider the near- science-fiction atmosphere that was around the rapid growth of artificial intelligence in the '80, and how it has been reconsidered since then.

More precisely, in his seminal paper, Anthony Hall identified seven myths about formal methods. Seven additional myths have been identified later by Bowen and Hinchey. These are false believe that industrials have about formal methods, and that considerably hinder their adoption in Industry.

The first seven myths (1990)

 * Formal methods can guarantee that software is perfect. Actually, formal method can prove that some artefact has some properties. If the properties that are proven are incomplete or inaccurate with respect to the actual requirements, or if the requirements are themselves incomplete or inaccurate, formal methods will not compensate such weaknesses.
 * Formal methods are all about program proving. It is true that program proving has been a very long-run topic in formal method because source code is an existing artefact exhibiting the features of formal language, including a notation that can be analysed by formal tools, and a semantics that is quite formal even if one can always argue about some details. However, Formal methods can also verify other artefacts such as system-level models, as done in the Deploy project, communication protocols, and requirements models, etc.
 * Formal methods are only useful for safety-critical systems. Formal methods tend to provide a very high level of assurance about some properties; and this is especially desirable in safety-critical systems. However, other sectors have high assurance requirements, such as business, security-critical systems, etc. In the Deploy project, SAP and Space System Finland were deploying formal methods. Furthermore, Formal methods were also used in Deploy for instruction set architecture verification at XMOS. This was a business-critical issue. The choice of using formal methods or not is more related to the desired level of assurance than to a safety/security/business taxonomy.
 * Formal methods require highly trained mathematicians. The mathematics behind formal methods is easy. What is difficult is the engineering. Formal methods require one to precisely specify and reason about the system properties, etc. This level of precision tends to be much higher than the one reached in written specifications, hence more difficult to reach. Training delays are generally estimated to one or two weeks, with a trained teacher. See the dedicated FAQ's for more details on this point, for instance TSP-HM-1. It is however true that formal methods are about mathematics, and that majority of people tend to dislike mathematics, quickly sticking a "too difficult" stamp of it. Some formal methods can be hidden behind some domain-specific language, to hide the mathematical notation behind e.g. graphical notations à la UML. This is discussed in this FAQ in the success story Adoption Eased by Using Formal Models behind Domain Specific Notations, and the two specific FAQ CIF-EA-1 CIF-QAP-1.
 * Formal methods increase the cost of development. Formal methods shift the cost of development to late testing phase to early analysis phases. Managers tend to rely on the feeling that something is being developed to estimate the progress of their teams. Writing source code immediately tend to be less frustrating that developing models during as much as 30% of the project lifetime, depending on the technique in use. See the dedicated FAQ QI-PQAM-2 for more details on this point. It is also true that using formal methods dramatically changes the rate of identification of issues at each phase of development cycle. This is discussed in QI-PQAM-1.
 * Formal methods are unacceptable to users. Formal specifications help users understand what they get, simply because they precisely state the properties that are proven on the artefact. Formal specifications can be difficult to communicate in raw manner to non-trained individuals; just like reading source code might be difficult for non-computer scientists. Several techniques can be used to help this understanding, including: paraphrasing the formal specification into natural language (which turns to be quite easy), animating the formal specification (depending on the available animation technology), and demonstrating the consequences of the formal specification. Some industrial sectors are actually requiring formal methods ExFac-HM-2 and ExFac-HM-3.
 * Formal methods are not used on real, large-scale software. Several success stories are mentioned in this FAQ that have been carried by industrials, either within the project, with a high level of assistance, or outside the project, at the DA, with lower level of assistance. They were all carried on industrial projects of various sizes.

Seven More Myths (1995)

 * Formal methods delay the development process: there is a whole FAQ dedicated to this issue QI-PQAM-2. It is also true that using formal methods dramatically changes the rate of identification of issues at each phase of development cycle. This is discussed in QI-PQAM-1.
 * Formal methods are not supported by tools: formal methods require specific tools to be developed to handle them such as theorem provers, model-checkers, etc. This technology is of paramount importance for the successful deployment of formal method, as it provides the degree of automation that makes formal methods attractive . Obviously, it is quite frustrating to use a method that requires one to perform a lot of systematic checks while one might have the feeling that a machine would perform better on such tasks. Formal methods are such kind of methods. The technology that is needed to deploy formal methods with the adequate automation is becoming mature, and as the computing power available to common desktop platform is increasing as well, such tools can be developed now, and provide the support they are expected to provide.
 * Formal methods mean forsaking traditional engineering design methods: Formal methods provide a formal notation, also known as "formal specification language", and some form of deductive apparatus, also known as "proof system". As such, they are not actual development methods; they should be called tooling or technique. They will not make up for the engineer skills and know-how, and they need to be integrated in some development process, just as engineer learned to use calculators in the early days of computer science.
 * Formal methods only apply to software. Formal methods apply also to hardware or system engineering. Formal methods reason on some input that need to be made precise enough to be amenable to automated analysis. Software artefacts tend to often match this condition, giving rise to this myth.
 * Formal methods are not required. Formal methods deliver a very high assurance level on the artefact they analysed about the property that was analysed. This high level of assurance might sometime be considered as overkill, but this is to be considered on a case-by-case basis. It is true that sectors exhibiting some degree of criticality tend to adopt formal methods more easily than sectors without such criticality. Some industrial sectors are actually requiring formal methods ExFac-HM-2 and ExFac-HM-3.
 * Formal methods are not supported: The general principle that formal method aim at systematically verifying things is well-established. One also needs some framework in which one can use this principle. This includes a concrete language and the necessary tooling. Such languages are now well-established. One can consider B, Event-B, Z, VDM for instance.
 * Formal methods people always use: Not all properties can be formally checked on a given system in a practical way. For instance, the run-time of some source code is estimated through benchmarking, user interfaces are tested manually, etc. Formal method people tend to generally focus on a fragment of the system under consideration, focusing preferably on the most critic, the most complex, or the most amenable to formal analysis.

Lessons Learnt from DEPLOY
From the experience in the DEPLOY project, it seems that industrials tend to avoid changing their development process because of the incurred cost: switching people to a new technology takes time, some people do not adapt and are therefore wasted, there is a risk in the first project, etc. The biggest driver in industry is money. The second biggest driver is when they are obliged to do something, e.g. to comply with some regulation. For instance, the famous line14 metro that was developed a decade ago was developed using the B formal method because the customer explicitly required this method to be used. A third reason from our Deploy experience is that a manager might be blamed for a failure due to his attempt to deploy new "exotic" development methods such as formal methods, but he will less likely to be blamed for a failure arising because he pushed his team to keep using methods that were successful so far.