[SystemSafety] A Fire Code for Software?

Fri Mar 9 20:53:09 CET 2018

David,
Your experience is very different than mine. I work with many companies each year, in both consulting and training roles. A numbers of those customers are investment banking organizations. I have been unable to perceive any significant difference between software developers inside investment banking vs. outside.

At least in the US, salary differences are driven much more by geography than by application domain. That developers in investment banks make more than avionics developers in the US is more explainable by the banking people tending to work in New York City, Chicago, San Francisco, and Los Angeles while the avionics developers tending to be in Iowa, Arizona, Kansas, and Michigan. Salaries overall vary widely between these areas. I don’t see a big difference between salaries of avionics vs. banking developers when they are in the same city (specifically, for example, Seattle and Los Angeles). Certainly not by a factor of three.

Regarding hiring practices, I also don’t see any perceivable difference there either. The talents of the people I work with inside of investment banking is really no different than the people I see working outside. Actually, I would say that the people I have worked with in avionics do tend to be much more professional than those anywhere else. I suspect that is in no small part driven by DO-178C/ED-12C and the culture & requirements around certification.

I can’t dispute what you say, but are you sure it applies to ALL investment banking houses and not just the one you worked at?

Regards,

— steve

From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de<mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de>> on behalf of David Crocker <dcrocker at eschertech.com<mailto:dcrocker at eschertech.com>>
Date: Friday, March 9, 2018 at 4:31 AM
To: "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?

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<mailto: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/c432c525/attachment-0001.html>