[SystemSafety] A Fire Code for Software?

[Steve Tockey]

Andrew,
I agree 100%. But I would actually take it even farther.

I am already on record as having said (referring to the software industry as a whole),

“We are an industry of highly paid amateurs”

Claiming that one is an engineer simply because the words “software engineer” are printed on one’s business card are simply not sufficient. I strongly recommend that we start a parallel effort to the recent “don’t call them bugs, call them defects” movement (Are you paying attention, Chris Hills?). In this nw movement, anyone who uses the term “software engineer” is required to:

A) provide a reference to a definition of the term “engineer(ing)” that has been accepted by already-recognized engineers (e.g., Civil, Chemical, Mechanical, Industrial, . . .)

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<mailto:andrew at andrewbanks.com>>
Date: Wednesday, March 7, 2018 at 10:12 PM
To: Steve Tockey <Steve.Tockey at construx.com<mailto:Steve.Tockey at construx.com>>, 'Andy Ashworth' <andy at the-ashworths.org<mailto:andy at the-ashworths.org>>
Cc: "systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>" <systemsafety at lists.techfak.uni-bielefeld.de<mailto: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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20180308/ef1cbc02/attachment.html>