[rednerrus]

The biggest problem with offshore engineering teams is their dedication to delivering exactly what you ask for. One of the qualities of a good software developer is to take the requirements and interpret what needs to happen then deliver appropriately. Delivering exactly what's written without thinking about the implications is a huge problem and one of the biggest issues I've run into working with offshore teams.

[jkic47]

I agree with you on the problem with offshoring, having done this myself in a previous role in a regulated industry.

However, the offshore team are usually not intended to act as domain experts. In fact, they were very likely explicitly proscribed from interpreting the specifications handed to them to guard against them trying to act as domain experts and delivering something different from expectations.

As such, they were (likely) not the ones who specified that MCAS should silently turn itself on after a pilot turned it off. That misjudgment probably lies with the engineering team who made that design decision, and it had tragic results.

[rramadass]

> However, the offshore team are usually not intended to act as domain experts. In fact, they were very likely explicitly proscribed from interpreting the specifications handed to them to guard against them trying to act as domain experts and delivering something different from expectations.

Finally! Thank you for stating this explicitly.

In safety critical systems specifications are everything and is always done by a team of domain experts to an enormous amount of detail (with optional formal methods verification). The actual coder has to just use the chosen implementation language carefully to meet the specification with no personal interpretations; everything has to be explicit and documented.

[solarwindy]

And yet, the specification is not what executes. If the code can be written by a domain expert, why compromise? If nothing else, more time spent working on the problem by a domain expert gives more opportunity to identify deficiencies in the specification, or the ability to meet the specification within the constraints of the actual execution environment.

Never mind that this idea of an offshore team diligently implementing the spec to the letter hand-waves away the software engineering, as if it’s a mere implementation detail not intimately connected to the system delivering the desired safety and performance characteristics.

[carlmr]

>more time spent working on the problem by a domain expert gives more opportunity to identify deficiencies in the specification

So much this. This is happening in other industries, too. Domain experts are also becoming less expert because of lack of proper feedback about their designs.

It's great to have a spec, but you should understand what's happening with the spec and how it applies to the actual code that executes.

With software we can get software that is very close to being an executable spec. By adding a layer of indirection we make everything harder.

[rramadass]

Developing Safety Critical Systems is nothing like developing "ordinary" systems. The stakes are so much higher that absolute rigour at every step is demanded and enforced. This is why "Software Engineering Process" methodologies were invented and enforced using "Formal Methods". When this rigour is lost you have catastrophic system failure like in the "current-day" Boeing company.

> Never mind that this idea of an offshore team diligently implementing the spec to the letter hand-waves away the software engineering, as if it’s a mere implementation detail not intimately connected to the system delivering the desired safety and performance characteristics.

If the "offshore" team does not have the requisite Domain Expertise (which seems to be the case here), then it is Boeing's job to provide rigorous specifications and more importantly have safety checks/verification/tests/etc. in place to guarantee "correctness to spec." Problems in the specifications itself are the responsibility of the Boeing Design/Engineering team.

[UK-Al05]

The problem is domain experts aren't actually that good specifications either.

Do you know who is trained to be good at spec'ing software? Software engineers.

[rramadass]

You have missed the point.

Domain Expertise is an absolute necessity to come up with Rigorous Specifications and in particular; for Safety Critical Systems.

If they can be done by a single person (whatever be his role name) all the more better but usually for Safety Critical (and highly specialized) Systems that is not possible and hence you need two (or more) people.

[struant]

If just deliver exactly what you are told to, you aren't doing any "engineering" at all.

[datavirtue]

Right,I just spend a little extra time on prompts and get much better, faster, work done completely stress free.

[DanielHB]

Coming from one of those countries where a lot of engineering gets offshored to, the best and brightest engineers in those countries DO have options (no, not just immigrating to a rich country) and won't be a code monkey for multinationals.

I have been to IBM offices in São Paulo a few times and let me just say, although they paid reasonably okay salaries it wasn't the first choice of work for most engineers...

And that is on top of the problems you are describing.

[Log_out_]

Now imagine a constraint written in management legales. "The system has to always augment flight characteristics to avoid system envelope violations. Should the pilot choose to deactivate the system temporarily, the system must return to enhanced flight characteristics as soon as the pilot stops signaling the intent to fly without the system. "