One of my coworkers fleshed out an important and complex component that absolutely had to be logically correct, by using TLA+ modelling.
It was the first time he'd used TLA+ (or TLA) at all, and it took a bit of experimenting to get used to it, but he soon generated a solid logical model and exposed a number of fringe flaws in the original proposed solution.
From TLA+ model to completed Java application took very little time at all, the logic was all there already, it just needed fleshed out in the language. It was also easy to split the work out amongst multiple programmers. He's argued that the total time, including learning TLA+, took less time than writing the application from scratch in Java and discovering the bugs as they went along.
About the only thing he disliked with it was that almost all (if not all) the tooling around it require Eclipse, and he hates that IDE with an almost unholy passion :D
> One of my coworkers fleshed out an important and complex component that absolutely had to be logically correct, by using TLA+ modelling.
This is nothing to do with you or your statement, but this is the pre-eminent issue in our industry. Everything absolutely has to be logically correct or we expose users to flaws in both security and stability that can in extreme cases be the difference between life or death and in regular cases be the difference between being cracked or not.
That's an exaggeration by far: only the tiniest subset of systems can kill people if they fail. Hacks happen by the millions with headaches being the main result along with lost time and money. Even most security-critical systems are the same with the main targeting being done for espionage (data theft). High assurance security focuses on what can get people killed (esp military use) with an emphasis on tools such as these. I've never seen a mainstream FOSS or proprietary product show evidence of an EAL6+ development process, though. Even security community largely throws stuff together plus some code review.
Best to keep it real about risks so your solutions match requirements. Most companies are happy to sell patches to broken software or offer software that passed many checklist items for compliance. They have lawyers for the rest.
I agree that ideally we should set our baseline much higher. It's why I promote low-defect methodologies, code reviews, static analysis, and languages (eg Ada, Haskell) that prevent/catch most problems early. The few empirical studies done on such things show it actually saves money with occasional productivity boost for one reason: huge reduction of debug time.
And the satisfied customer effect can't be ignored. ;)
It was the first time he'd used TLA+ (or TLA) at all, and it took a bit of experimenting to get used to it, but he soon generated a solid logical model and exposed a number of fringe flaws in the original proposed solution.
From TLA+ model to completed Java application took very little time at all, the logic was all there already, it just needed fleshed out in the language. It was also easy to split the work out amongst multiple programmers. He's argued that the total time, including learning TLA+, took less time than writing the application from scratch in Java and discovering the bugs as they went along.
About the only thing he disliked with it was that almost all (if not all) the tooling around it require Eclipse, and he hates that IDE with an almost unholy passion :D