[SystemSafety] A Fire Code for Software?

[David Crocker]

Steve,

Amateurs yes, but highly paid no.

When I was looking for software development work several years ago, the
remuneration being offered by the investment banking industry was around
THREE TIMES the remuneration offered by companies writing
safety-critical embedded software (£120k including likely bonus vs.
£40k). So I worked in financial modelling infrastructure for an
investment bank for several years. I learned a lot from that. The
candidate screening and interviewing process was far more rigorous than
I have seen anywhere else. We rejected a lot of candidates that looked
good on paper, including several with PhDs from Cambridge, Oxford and
other leading universities. The result was that we had small teams of
highly skilled software developers who worked well together, with a
productivity at producing good, tested code many times higher than I
have seen anywhere else.

So the investment banks have nearly all the top-notch software
developers, leaving other sectors including safety-critical embedded to
pick up the dregs.

David Crocker, Escher Technologies Ltd.
http://www.eschertech.com
Tel. +44 (0)20 8144 3265 or +44 (0)7977 211486

On 08/03/2018 19:00, Steve Tockey wrote:
>
> 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
>
>  
>
>  
>
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE

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