Specification-driven design (bobkonf2022)

Do you, too, think that “implementation-defined” is a derogary term? Let me describe how I have pushed againt that, and for development model that puts an abstract specification of the system to be built in a central, pivotal position, flanked by a clean-room, decoupled “reference implementation” and a “specification acceptance test”, using functional programming for good effect in both cases. Many developers tend to focus on the “how”, and less on the “what”, of what they are building. This is not bad per se, but if left unchecked, this may lead to systems with an “implementation-defined surface”, with a organically grown interface that leaks abstractions and exposes implementation details. To counter this effect, one can write a proper specification for the system. A document that, in prose and or math, precisely describes the interface of the system, but also its behavior, i.e. its semantics. This decouples the outward-facing aspects of the system from the internals. On top of that one can write a reference implementation of the system, based only on the specification. This checks and clarifies the specification, and by comparing the behavior of the two implementations, one can triangulate bugs and detect when implementations and spec went out of sync. To make things even more rigid, one can add a conformance test suite, again based soley on the specification, and probes an implementation and checks for certain behaviours. This can be integrated into the developent process, e.g. as a CI check, and additionally keep the implementations honest. All in all, this gives you a clear picture of the essence of your system or service, a place to discuss changes between stakeholders on either side of the interface without getting distracted by implementation designs, insulates your users from implementation changes and gives your developers a clearly demarked space to go wild within. about this event: https://bobkonf.de/2022/breitner.html