Todos
← Back to Squawk list
Boeing outsourcing of software development
Much has been written about the 737Max's problems, but this topic has hardly been mentioned. The author writes for Bloomberg, but this was published in the Sydney Morning Herold. (www.smh.com.au) Más...Sort type: [Top] [Newest]
Being a retired IT professional some of these problems are not new, the big one being well written specifications. Sometimes they are almost nonexistent. All of these exist in ALL software development at some point. The thing that prevents that to some extent is to always do software development on site where the work can be supervised by the client using IT professionals that are hired and paid by the company the software is being written for. It seems to me that Boeing didn’t do this or they were cutting costs by not using redundancies for the MCAS. There is also the problem of too much dependence on automation.
how many more nails in the coffin of boeing management is required before complete housecleaning , including walking them out the door without benefits and pensions? This is leadership, or is it shopping for the cheapest way to do thing, regardless of meeting safe standards?
Including walking them out the door and into prison. Their management led to the deaths of 346 people. They should stand trial in Ethiopia and Indonesia.
From 2010 to 2017, I was working on the hardware of a emerging developmental software-based electronics system.
Anytime the software dev. folks made a change, they spent days "regression" testing the software.
I bought a new motorcycle in 2014, the 1st year for an "in-dash" infotainment system.
There were many silly little problems and every time a SW update was done, something else would go awry. After being assured by the SW Dev. folks the problems were all in the SW coding and lack of proper re-testing, I eventually called the manufacturer of the MC and then the radio manufacturer.
I assume I became such a pest, eventually the radio manufacturer told me "The software is being developed by a third party company in India, we have no control over that" WTH?
I thought about finding that company and contacting them then realized "Hell I can't get a simple problem solved when I contact an off-shore call center about anything".
IMO, In The Long Run, all this "Outsourcing" regardless of the product is costing these companies money not saving it.
Anytime the software dev. folks made a change, they spent days "regression" testing the software.
I bought a new motorcycle in 2014, the 1st year for an "in-dash" infotainment system.
There were many silly little problems and every time a SW update was done, something else would go awry. After being assured by the SW Dev. folks the problems were all in the SW coding and lack of proper re-testing, I eventually called the manufacturer of the MC and then the radio manufacturer.
I assume I became such a pest, eventually the radio manufacturer told me "The software is being developed by a third party company in India, we have no control over that" WTH?
I thought about finding that company and contacting them then realized "Hell I can't get a simple problem solved when I contact an off-shore call center about anything".
IMO, In The Long Run, all this "Outsourcing" regardless of the product is costing these companies money not saving it.
My sister worked for a company that depended on controct programmers from India.
She said it was a 'shit show'. The 'screw ups' were incremental. She was the lead for their QC team in New Hampshire, and she was always stunned at the errors that the Indian programmers introduced into their software.
Once, someone apparently just grabbed a 6 month old code base, did their change, and submitted it for review. She called, practically in tears. 'How in the hell!'
So management got a 'Great Idea(r)', we'll send our QC team to India to meet with the programmers assigned to the project, and maybe their dedication will rub off on the constant cycle of programmers she had to deal with. I mean, she was in THEIR time zone. She got the the office while it was still dark, and babysat the programmers in India, in real time.
So, she and her team, several quit at being 'asked' to go to India, and she sat with their management, and met with the 'lead programmers', and experienced the smells, and dysentery of India.
Half the 'team' in New Hampshire quit, the other half said, in no uncertain terms, they would NOT GO TO INDIA, and the problems continued.
So, handling programmers almost half a world away, with a definite language barrier is going to be MASSIVE, and even more so in an industry where if they don't look at every character, and test that 'software' every way that it could fail, they are stupid, and the lives that were lost in the two crashes were negligent HOMICIDE, and the management of Boeing needs to be frogmarched out of their office, and turn in their golden parachutes at the door.
Hired India programmers is a crappy way to insure your product doesn't kill people. My sister said that they spent likely more testing their product than they would have if their IN HOUSE programming team has done the damn job in the first place.
Likely, Everett thought that they could trust the programmers, the hired guns, they forgot that the minimum wage India programmers aren't going to die when that software fails, and the plane succumbs to gravity. People die management goes 'Oh, crap', and they keep testing fate...
She said it was a 'shit show'. The 'screw ups' were incremental. She was the lead for their QC team in New Hampshire, and she was always stunned at the errors that the Indian programmers introduced into their software.
Once, someone apparently just grabbed a 6 month old code base, did their change, and submitted it for review. She called, practically in tears. 'How in the hell!'
So management got a 'Great Idea(r)', we'll send our QC team to India to meet with the programmers assigned to the project, and maybe their dedication will rub off on the constant cycle of programmers she had to deal with. I mean, she was in THEIR time zone. She got the the office while it was still dark, and babysat the programmers in India, in real time.
So, she and her team, several quit at being 'asked' to go to India, and she sat with their management, and met with the 'lead programmers', and experienced the smells, and dysentery of India.
Half the 'team' in New Hampshire quit, the other half said, in no uncertain terms, they would NOT GO TO INDIA, and the problems continued.
So, handling programmers almost half a world away, with a definite language barrier is going to be MASSIVE, and even more so in an industry where if they don't look at every character, and test that 'software' every way that it could fail, they are stupid, and the lives that were lost in the two crashes were negligent HOMICIDE, and the management of Boeing needs to be frogmarched out of their office, and turn in their golden parachutes at the door.
Hired India programmers is a crappy way to insure your product doesn't kill people. My sister said that they spent likely more testing their product than they would have if their IN HOUSE programming team has done the damn job in the first place.
Likely, Everett thought that they could trust the programmers, the hired guns, they forgot that the minimum wage India programmers aren't going to die when that software fails, and the plane succumbs to gravity. People die management goes 'Oh, crap', and they keep testing fate...
Sounds so much like the shit shows of off shore call centers. It's fine if they want to get cheaper help, but for crying out loud, get the help that knows WTH is going on, how it's going on and why.
Something in that report has me puzzled...Boeing said the "cockpit warning light" was an "option"...so how is it an issue if it was working according to their "plan"? "The Chicago-based planemaker also said it didn't rely on either firm for another software issue disclosed after the crashes: a cockpit warning light that wasn't working for most buyers." Won't work if it was an "option"
Something in that report has me puzzled...Boeing said the "cockpit warning light" was an "option"...so how is it an issue if it was working according to their "plan"? "The Chicago-based planemaker also said it didn't rely on either firm for another software issue disclosed after the crashes: a cockpit warning light that wasn't working for most buyers." Won't work if it was an "option"
Here’s the opinion of one long experienced Sw Dev - albeit with experience in slightly different industries.
The entire situation is indicative of the risk acceptability vs bottom line costs that prevails these days. Overwhelming importantance is placed on costs & timelines vs quality. It’s basically become acceptable if not expected to have flaws, recalls & the like - no matter how critical the nature of the deliverable is. It’s now common place to not take the proper time, pay low wages, & not support the concerns & undesired analysis results found & communicated by reputable employees that will not accept anything less than what is needed to ensure software & products are designed, developed & function properly Before they are delivered/implemented.
Many of the latest “fads” of software development demand these kinds of issues/concerns/incorrect results be voiced. Yet when those techniques are implemented & issues are questioned/identified in some instances management doesn’t want to hear anything negative & occasionally even crucifies that “whistle/blower”. Thus software ican be installed & products delivered that may well have flaws. And those flaws can inconvenience or even hurt/maime/kill people as well as cause untold property destruction - plus take considerably more work & time to resolve.
The legal results may be deemed “better/justified” from a financial aspect when weighed against missing delivery dates or the bottom line costs.
This is a worldwide issue. At some point we as a country & even race need to demand & be able to expect better. Quality MUST prevail - at least when lives are at stake - if not always...
The entire situation is indicative of the risk acceptability vs bottom line costs that prevails these days. Overwhelming importantance is placed on costs & timelines vs quality. It’s basically become acceptable if not expected to have flaws, recalls & the like - no matter how critical the nature of the deliverable is. It’s now common place to not take the proper time, pay low wages, & not support the concerns & undesired analysis results found & communicated by reputable employees that will not accept anything less than what is needed to ensure software & products are designed, developed & function properly Before they are delivered/implemented.
Many of the latest “fads” of software development demand these kinds of issues/concerns/incorrect results be voiced. Yet when those techniques are implemented & issues are questioned/identified in some instances management doesn’t want to hear anything negative & occasionally even crucifies that “whistle/blower”. Thus software ican be installed & products delivered that may well have flaws. And those flaws can inconvenience or even hurt/maime/kill people as well as cause untold property destruction - plus take considerably more work & time to resolve.
The legal results may be deemed “better/justified” from a financial aspect when weighed against missing delivery dates or the bottom line costs.
This is a worldwide issue. At some point we as a country & even race need to demand & be able to expect better. Quality MUST prevail - at least when lives are at stake - if not always...
Indian engineers tend to be well educated and intelligent, but the vast majority are fresh from university and have little grounding in the final use.
There is often a reliance upon machine written software.
Communication between teams is poor and assumptions are continually made.
Well written specifications can be difficult to find.
Reviews at all stages happen infrequently.
Contracts exist where suppliers can provide untested software.
Management reaction is to have a part of the team write a software quality guide for the supplier :(
Timescales are generally unrealistic
When something in the build script doesn't work, someone fudges it with best intentions to get an overnight build out, and then the headaches start.
My employer has embarked upon another project under sub contract to another country that is well developed and same issues exist with software quality.
NASA/MIT documented many of the pitfalls of software development many years ago but it appears many organisations prefer to start from the ground up and make proprietary mistakes.