[SystemSafety] A Fire Code for Software?

[Michael Jackson]

Derek: 

> What recognition are we seeking and why would we deserve it?

The recognition deserved by reliable delivery of specific software-intensive systems of very high quality in every dimension that matters. 

There are many kinds of software-intensive system, each demanding its significant subset of the knowledge, skills, attitudes and practices that fall under the general umbrella of ‘software engineering’. Although this umbrella is common to many systems, the different kinds of system are also critically distinguished by their non-software parts and aspects. Among the possible specialisms at many levels, product specialisms are vital. 

25 years after the Therac-25 disaster there was a similar disaster in 2010 in which several patients were killed by software and related faults in radiotherapy machines. The purpose of radiotherapy machine software is to govern the behaviour of the ‘physical problem world’—that is, of all the relevant physical equipment and of all the people participating in the system behaviour. This software cannot be successfully developed except hand-in-hand with development of the whole system behaviour. This needs specialists who are software-engineers-for-radiotherapy-systems.

— Michael  

> On 9 Mar 2018, at 20:08, Derek M Jones <derek at knosof.co.uk> wrote:
> 
> Michael,
> 
>> .... We will never deserve or gain the recognition we seek until we too specialise appropriately.
> 
> What recognition are we seeking and why would we deserve it?
> 
> A very interesting take on the history of the drive for professionalism
> in software and how managers did not want too much of it (because it
> would reduce their authority):
> https://pdfs.semanticscholar.org/cecc/3e0a300cb35f45a4150fe28d763532cc08ba.pdf
> 
>> — Michael Jackson
>>  
>>> 
>>> B) Show how what they are doing on a day-to-day basis on their projects is consistent with that legitimate engineer-accepted definition
>>> 
>>> The vast majority of people in this industry can’t do either A) nor B).
>>> 
>>> 
>>> What happens most of the time in the software industry is no better than what I call “Resume Driven Development”. Major technical decisions are not made in the best interest of the organization, they are made based on what looks good on the developer’s resume.
>>> 
>>> 
>>> Regarding this so-called “paradigm shift to agile methods”, I claim that if you really understand what “agile” means then you recognize that it is nothing more and nothing less than a project management paradigm. And a project management paradigm—any, including waterfall—alone is not sufficient to either warrant calling “engineering” or assure delivery of reasonable software at a reasonable cost and schedule. A true engineer would know when a waterfall project management paradigm is and is not appropriate. A true engineer would know when an agile project management paradigm is and is not appropriate. A true engineer would make a decision on which project management paradigm to use based on what provides the best return on investment for the organization, and not what looks sexy on their resume. A true engineer would also know that a project management paradigm alone is not sufficient to assure delivery of  high-quality software in a cost-effective way. Delivering high-quality software cost-effectively requires:
>>> 
>>> *) a sane and rational approach to how the project is being managed
>>> *) a sane and rational approach to how requirements, design, and construction (coding) work is being done on the project
>>> *) a sane and rational approach to how quality work (inspections and/or other peer reviews, as well as testing) is being done on the project
>>> 
>>> 
>>> My second book is not titled “How to Engineer Software” by accident.
>>> 
>>> 
>>> 
>>> Cheers,
>>> 
>>> — steve
>>> 
>>> 
>>> 
>>> 
>>> From: Andrew Banks <andrew at andrewbanks.com>
>>> Date: Wednesday, March 7, 2018 at 10:12 PM
>>> To: Steve Tockey <Steve.Tockey at construx.com>, 'Andy Ashworth' <andy at the-ashworths.org>
>>> Cc: "systemsafety at lists.techfak.uni-bielefeld.de" <systemsafety at lists.techfak.uni-bielefeld.de>
>>> Subject: RE: [SystemSafety] A Fire Code for Software?
>>> 
>>> Hi Steve
>>>  And here is the rub:
>>>  
>>>>> My definition of “model based” involves creating and maintaining precise specifications of semantics:
>>>>> policies that need to be enforced and processes that need to be carried out.
>>>  It is the absence of this up-front work that is so prevalent in software (and systems-) engineering… even in formal development environments, engineers need to “get on with it” and let the requirements catch up.  Then throw in the paradigm shift to more Agile methods and it gets even more unpredictable.
>>>  But The Authorities seem to not care: Eg in the automotive world, despite standards such as ISO 26262 there is no statutory requirement to follow a formal development process… only “conformity of production” matters – and the type approval process doesn’t even mention the existence of software (or involve any checking of how it came into being), and just concerns itself with the physical characteristics of the vehicle.
>>>  Compare with civil engineering, where the detailed plans form part of the planning process, and implementation is controlled by strict building regulations, and independently monitored – and all components have to comply with appropriate standards.
>>>    Regards
>>> Andrew
>>>    _______________________________________________
>>> The System Safety Mailing List
>>> systemsafety at TechFak.Uni-Bielefeld.DE
>> _______________________________________________
>> The System Safety Mailing List
>> systemsafety at TechFak.Uni-Bielefeld.DE
> 
> -- 
> Derek M. Jones           Software analysis
> tel: +44 (0)1252 520667  blog:shape-of-code.coding-guidelines.com
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE