# Formal Methods: Just Good Engineering Practice?

DevFeed: [Formal Methods: Just Good Engineering Practice?](<https://devfeed.tech/articles/formal-methods-just-good-engineering-practice-12555.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2024/04/17/formal.html>)

Author: Marc Brooker

Published: 2024-04-17T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [Formal methods](<https://devfeed.tech/topics/formal-methods.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>), [API](<https://devfeed.tech/topics/api.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [formal-methods](<https://devfeed.tech/tags/formal-methods.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>)

## AI overview

The article argues that formal methods are an important part of good software engineering practice, particularly for large-scale, distributed, and critical low-level systems. It explains that their cost can be offset by reducing rework and the expense of changing systems after their APIs have acquired users.

## Source excerpt

Formal Methods: Just Good Engineering Practice? Yes. The answer is yes. In your face, Betteridge. Earlier this week, I did the keynote at TLA+ conf 2024 (watch the video or check out the slides). My message in the keynote was something I have believed to be true for a long time: formal methods are an important part of good software engineering practice. If you're a software engineer, especially one working on large-scale systems, distributed systems, or critical low-level system, and are not using formal methods as part of your approach, you're probably wasting time and money. Because, ultimately, engineering is an exercise in optimizing for time and money1. "It would be well if engineering were less generally thought of, and even defined, as the art of constructing. In a certain important sense it is rather the art of not constructing; or, to define it rudely but not inaptly, it is the art of doing that well with one dollar, which any bungler can do with two after a fashion." Arthur Wellington2 At first, this may seem counter-intuitive. Formal methods aren't cheap, aren't particularly easy, and don't fit well into every software engineering approach. Its reasonable to start with the belief that a formal approach would increase costs, especially non-recurring engineering costs. My experience is that this isn't true, for two reasons. The first is rework. Software engineering is somewhat unique in the engineering fields in that design and construction tend to happen at the same time, and a lot of construction can be started without a advancing much into design. This isn't true in electrical engineering (designing a PCB or laying cables can't really be done until design is complete), or civil engineering (starting the earthworks before you know what you're building is possible, but a reliable way to waste money), or mechanical engineering, and so on. This is a huge strength of software - its mutability has been one of the reasons it has taken over the world - but can a