I wanted to share this, which I found on the System Safety Mailing list: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
Martyn Thomas has enormous experience in implementing computer systems and was the founder of Praxis a company, now part of the Altran group, that became “internationally recognised as a leader in the use of rigorous software engineering, including mathematically formal methods.” He wrote in a thread about software:
I recall a lecture given by Dijkstra in 1973. A member of the audience asked “do your methods work on real world problems?” Dijkstra paused, and then said quietly “real world problems. Ah yes, those that remain when you have failed to apply all the known solutions”. Over the years, I have heard many excuses for failures to use professional engineering methods. “if we train the programmers, they’ll leave for a better paid job” “we can’t hire programmers who are willing to use that programming language” “universities don’t teach (maths, project management, quality control, planning, team working … …)” “the customer insists that we use this (buggy) middleware for compatibility” “modern software isn’t written – it’s assembled from lots of (buggy) COTS” “if we try to include that in the standard, industry will revolt.” “if we were to ask for that evidence, industry would charge us a fortune” … and many many more. Most software developers appear to have lost sight of the problem. Every week, I hear someone use the verb “test” when what they mean is “gain assurance that … is fit for purpose”; this reveals a dangerous, implicit assumption that “test-and-fix” is the only practical way to develop software. Most software is still written in languages without good data structures and strong type-checking. Most software requirements (and even interface specifications) are written in English (or another natural language) – perhaps with some diagrams that lack any rigorous semantics. Most projects have grossly inadequate change control. I rarely see a risk register that is worth anything (except as a demonstration that the project manager isn’t managing the project). Is there another trade that (a) builds complex, novel and critical systems using poorly-qualified staff, (b) almost exclusively uses tools that have major known defects, (c) builds systems from components of unknown provenance that cannot be shown to be fit for purpose and (d) nevertheless claims to be professional engineers? Surely it is self-evident that the current state of our profession is unsustainable. Let’s stop making excuses and look for ways to accelerate the changes that we know are needed.Martyn, it seems to me, is putting forward a very accurate view of the whole software arena. Even in the safety-critical arena there is still too little concern for these issues. How do we go about resolving this? Or is it too late to push the genii back into the bottle?
After all the stringent methods are applied, one is left with a complex system that at times tries to defeat itself, due to competition for resources. Worker functions are suspended during management functions, which depend upon the same faculties for interpretation and execution. Time to space translation on input and space to time for useful output. The disclaimer shipped with most software tells the truth: buyer beware.
There is a remedy, an alternative to TMs that is in and for the time domain vs being relegated to the space domain.
Details on request c.moeller@ieee.org