61–70 of 87 posts
Earlier quoted context omitted.
> If yes, then raise problem and refuse to implement / avoid killing people. Often, software engineers are pipped, written up, berated, stack ranked - and churned via various management processes for doing exactly as asked for. Until the culture of the company aka ALL levels of management changes to full accountability without blaming the actual engineers, nothing will change. The current corporate structure just isn…
Perhaps software engineers looking for accountability would like the same level of liability that is enjoyed by their peers in civil, mechanical, mining, and electrical engineering?
What sane person would willingly put up code that can kill others on purpose... so we're left with incompetence.
Accountability, if implemented, should be company wide.
Right now issues have passed design stage, implementation, qa... with this sort of failure you have management to blame for not putting up processes in place so its caught / hiring and keeping competent enough people.
This is sort of expected as they optimized cost to the detriment of everything else.
The article seems to conflate engineering salaries in a low cost of living country with the quality of the software. As I understand it, the software performed exactly as designed, forcing the nose of the plane downwards to counter the upwards torque produced by the engines being offset relative to the centre of gravity of the plane. Mentour Pilot had a great episode on the two tragic accidents. It appears that Boein…
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.
Earlier quoted context omitted.
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, the…
> 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…
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.
Earlier quoted context omitted.
My experience is that contract work like this ends up being done by ordertakers; the contractors execute the design, no matter how stupid. Whereas, the best performing companies hire engineers who are empowered to understand the goals, understand the problem, and push back when appropriate. The results are much better, because the people working on each system, understand it deeply and care. A low-cost contractor isn…
Often this is the entire point. The in-house staff are seen as obstructionists, whereas outsourcers provide the equivalent of meat robots. Many managers far prefer the latter over the former.
Earlier quoted context omitted.
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, the…
> 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…
Do you know who is trained to be good at spec'ing software? Software engineers.
Earlier quoted context omitted.
> 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…
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 imple…
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.
Earlier quoted context omitted.
> 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…
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.
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.
Earlier quoted context omitted.
> 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…
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 imple…
> 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.
> recalled one manager saying at an all-hands meeting that Boeing didn’t need senior engineers because its products were mature. Shame. Industrial companies, if you decide as pincher, you will be doomed in your little world... as it always has been :)
Most big "industrial-like" product companies are pinchers when it comes to SW. They offshore a lot hence why they pay SW devs so little. And it mostly works for them. It works for them, because like Boeing said, they have old battles tested processes which usually means big mistakes can easily get caught ahead of time. And if big mistakes don't get caught they usually can't kill anyone and generate a huge public scan…