[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.