[SystemSafety] A Fire Code for Software?

Derek M Jones derek at knosof.co.uk
Fri Mar 9 21:08:05 CET 2018


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


More information about the systemsafety mailing list