Formal methods encompass a wide choice of techniques and tools for the specification, development, analysis, and verification of software and hardware systems. Formal methods are widely applied in industry, in activities ranging from the elicitation of requirements and the early design phases all the way to the deployment, configuration, and runtime monitoring of actual systems. Formal methods allow one to precisely specify the environment in which a system operates, the requirements and properties that the system should satisfy, the models of the system used during the various design steps, and the code embedded in the final implementation, as well as to express conformance relations between these specifications. We present a broad scope of successful applications of formal methods in industry, not limited to the well-known success stories from the safety-critical domain, like railways and other transportation systems, but also covering other areas such as lithography manufacturing and cloud security in e-commerce, to name but a few. We also report testimonies from a number of representatives from industry who, either directly or indirectly, use or have used formal methods in their industrial project endeavours. These persons are spread geographically, including Europe, Asia, North and South America, and the involved projects witness the large coverage of applications of formal methods, not limited to the safety-critical domain. We thus make a case for the importance of formal methods, and in particular of the capacity to abstract and mathematical reasoning that are taught as part of any formal methods course. These are fundamental Computer Science skills that graduates should profit from when working as computer scientists in industry, as confirmed by industry representatives.

In addition to the major UK contributions to research underpinning formal approaches to the specification and development of computer systems—and perhaps as a consequence of this—some significant attempts to deploy the ideas into practical environments have taken place in the United Kingdom. The authors of this article have been involved in formal methods for many years and both had contact with a significant proportion of this history. This article both lists key ideas and indicates where attempts were made to use the ideas in practice. Not all of these deployment stories have been a complete success and an attempt is made to tease out lessons that influence the probability of successful long-term changes to software engineering.

Autonomous decentralised systems must be dependable or they will be unhelpful, at best, and may cause serious harm. Despite major advances in theoretical computer science and software engineering, industrial practice has not kept pace and most software intensive system development projects fail. If we are to achieve the benefits promised by new system architectures, industry will have to adopt much more rigorous software engineering practices, and universities will have to extend the amount of software engineering they teach, and to use such methods routinely on their own projects.

The shape of the Year 2000 problem around the world is becoming clearer, as many companies finish building their inventories of affected systems and processes, and are able to assess the time and resources they will need if they are to reduce their risks to the minimum. For two years, I led Year 2000 services for one of the world's largest global management consultancies, seeing projects in most industries and in many of the world's leading economies. This is a snapshot of what I have learnt.

Conclusion Well-designed computer systems can be safer than hardwired alternatives, and computer systems can control processes which are too complex for hardwired solutions, or where the hardwired solution is uneconomic.