[SystemSafety] A Fire Code for Software?

Fri Mar 9 21:39:02 CET 2018

Steve,

Of course I can't generalise my observations to all investment banking
houses. However, there is quite a lot of mobility of staff between IBs
in the London area; so I doubt that the other IBs paid significantly
less than the one I worked at. The fact that the IBs were located mostly
in London and the safety-critical systems development companies mostly
outside London (but often within commuting distance) will have skewed
the salaries a little.

But the the software developers that I worked with in investment banking
were far more productive (in terms of producing tested and working code)
than I have come across anywhere else.

Regards

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

On 09/03/2018 19:53, Steve Tockey wrote:
>
> 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
>

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