EEVblog Electronics Community Forum
General => General Technical Chat => Topic started by: Johnny10 on June 29, 2019, 03:15:08 pm
-
OK, so maybe the stock price has not bottomed yet?
Not to say you can't find good engineers working for this money in foreign countries.
-
https://www.marketwatch.com/investing/stock/ba (https://www.marketwatch.com/investing/stock/ba)
It has definitely not bottomed. It's barely shaking a bit. I guess cost reduction still wins at this point. ::)
-
They sold 5000 of the 737 MAX you think there would be money for talented, experienced, well paid software engineers?
-
They sold 5000 of the 737 MAX you think there would be money for high paid software engineers?
I'm sure that there was but the CEOs wanted it for their bonuses. Don't you understand how modern business works? Most are operated for the benefit of the CEOs, top executives and the LARGE share holders, not for the employees or the consumers or for the regular share holders.
-
Sadly not surprising. Programming tends to be outsourced to the lowest bidder now days, companies don't really care about quality.
My company outsources most coding to a company called CGI and they are horrible. What I don't get is that they also charge so much, it ends up being more expensive than if they just did it in house. Something as simple as changing the colour of a button ends up costing like 20 grand and several months of negotiating and planing. I just don't get it, it's absurd.
-
We tried outsourcing some of our programming to India about 28 years ago and it was a complete and utter disaster. The initial cost estimate was about 1/3 of what it would have cost us to do it but in the end it costs us at least twice as much. The Indians had NO version control and every time that we found a bug (there were MANY) they would eventually fix it but most of the time they fixed an OLD of date version and then sent that back to us. We had to retest EVERYTHING and due to them reusing an old SW version we would frequently find old bugs that had previously been fixed. Over and over and over again. It was the software version of the tiny clown car with an endless stream of clowns getting out of the car. Also like the clown car, they were turning around and getting right back into the car again from the other side so that they could pop out again.
I came onto that program after it was already underway and was supposed to be finished in 4 months. I left about 26 months later and it still had major problems. What was supposed to have taken one year lasted over two years and I don't know if they ever got it all fixed.
And FWIW I still see the exact same kind of repeating problems today on the websites of other large international companies. Ancestry.com and FedEx.com just to name two of them.
-
This kind of problems are rampant in the industry. And they are caused by current management culture. Managers view everything as a success as long as they manage to reduce costs, time and meet a deadline. Anything that gets in the way, be it intentions to improve quality of the product or security concerns, is labeled as a "problem" and the engineers who talk about that need to be put in their place. Because what do they know, they are like children and they don't understand anything about being successful and getting things done. (<- that's irony, of course, just in case)
What's changing now is that previously this sort of crap was limited to business software and things like computer games, where it caused stress and suffering for the end users, but not much besides that. Now it's going full speed into mission-critical systems and disasters will happen again and again.
The only solution I see is that we as engineers should put a full stop on shit like this and refuse to deliver low quality or unsafe products. They can't outsource everything and they definitely need engineers. So we need to be more aware and united to prevent things like this. They will never understand anything without a pressure from the bottom, but it must a significant pressure, not just some complaints after some horrible disaster actually happened and people died.
-
This kind of problems are rampant in the industry. And they are caused by current management culture. Managers view everything as a success as long as they manage to reduce costs, time and meet a deadline. Anything that gets in the way, be it intentions to improve quality of the product or security concerns, is labeled as a "problem" and the engineers who talk about that need to be put in their place. Because what do they know, they are like children and they don't understand anything about being successful and getting things done. (<- that's irony, of course, just in case)
What's changing now is that previously this sort of crap was limited to business software and things like computer games, where it caused stress and suffering for the end users, but not much besides that. Now it's going full speed into mission-critical systems and disasters will happen again and again.
The only solution I see is that we as engineers should put a full stop on shit like this and refuse to deliver low quality or unsafe products. They can't outsource everything and they definitely need engineers. So we need to be more aware and united to prevent things like this. They will never understand anything without a pressure from the bottom, but it must a significant pressure, not just some complaints after some horrible disaster actually happened and people died.
I think the battle between inexperienced management (i.e. those who haven’t been burned before) and experienced staff (i.e. engineers and others who have been burned before) is nothing new: it’s just part of the human condition. There will always be new upstarts coming up with what they think are better ways of doing things, and telling the old veterans that “things are different now, you just don’t get it”. From building stone cathedrals in the 12th century, to steam engines in the 18th century, to Elon Musk and his landable/reusable boosters today. How many Saturn V alumni would have laughed at the idea of landing and reusing Musk’s boosters before that technologically beautiful tandem landing months ago?
Unfortunately, many of the “new” ideas, i.e. the ones that the experienced folk resist for very good, empirical reasons, are still doomed to failure, as they have failed in the past, and for usually the same reasons (like offshore software development). It is the nature of human ignorance and pride to think that “I can do better than the old guard; I can do and see things that they cannot”. Yet the nature of technological progress has, in many cases, demonstrated this to be true, however galling to the old guard that may be: from Socrates to Newton to the present, some things fall and are replaced with new, and some things just seem absolute and will never change. But it’s impossible to tell which is which.
The underlying problem is that without “let’s try this again my way”, it’s impossible to tell if things actually “are different” now for a given undertaking. It is a truism that “to the risk-takers go the rewards”, and since the “new management” generally has less to lose than the old experienced crowd, caution, based on prudent thought and experience, gets thrown to the wind. Combine that with the use of “other people’s (stockholder) money”, and not having any real skin in the game, means that the sweet lies of the offshore software outsourcers will continue to entice software development managers who haven’t yet known the joys of managing a team of bungling coders working with ambiguous requirements a dozen timezones away.
At my age, I’ve given up trying to stop inexperienced managers from making the same stupid decisions I’ve learned from in the past: Instead I just consider myself the “hired hand”, provide my very detailed input for consideration, and then just shrug if it gets ignored or shunted off under the “things are different now” rationalization. I too was once one of those “I can do it better than you, old man” kids in my 20’s and 30’s, and pretty much knew everything then, lol, just like the inexperienced managers of today. Human nature will never change.
-
The engineering profession is fucked.
If all we can do is vote with our feet- quit the job at the mega corp that is making it impossible to do safe products - we have a big problem.
Imagine quitting Boeing over their scumbag ethics, and having to look for another job. There's not a lot of aerospace companies in the world. You would blow up your career and not change anything, they will just hire a replacement noob engineer for cheap and the world keeps turning, even after a few plane crashes and hundreds of deaths.
I've worked on products that can kill people, cause explosions or break limbs, electrocute. Very nerve wracking.
Walked out of an engineering job because I would not be given the time to do the safety testing. Anyone can be an "engineering manager" and instruct you to subvert safety, testing etc. in order to save time and get the product to market. Of course, you are somehow still the responsible person. Wife and kids, bills to pay - you'll do what's needed to keep your job.
Boeing's strategy to compete with Airbus- fire all the senior engineers and then farm out development, should be a textbook case. Boeing saves millions in wages and loses billions on greed.
"... one manager saying at an all-hands meeting that Boeing didn’t need senior engineers because its products were mature. “I was shocked that in a room full of a couple hundred mostly senior engineers we were being told that we weren’t needed”.
So I don't see anything to stop engineering from being treated as a commodity, with the intangibles such as quality and safety of design having a price tag a scumbag CEO knows about.
Instead of making the corporation efficient, clear-cutting staff is Muilenburg's genius.
OP's source: https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-737-max-software-outsourced-to-9-an-hour-engineers (https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-737-max-software-outsourced-to-9-an-hour-engineers)
-
The problem is, can anyone prove with concrete evidence that outsourced engineering is more inferior than US engineering.
In other words, how can they prove the chance of f*ing up by Indian coders is higher than US coders, or is this just a fluke.
It's not as simple as engineers in one country being superior to those in another. A significant part of the issue is that development is outsourced abroad for one reason only, and that is reduced cost. The companies that set up overseas get the job by submitting the lowest bid and they are able to submit the lowest bid by cutting every corner they can, insulated from any direct oversight by the large distance. There are loads of talented engineers in India and elsewhere but most of them get jobs at reputable companies or come to places like the USA to work. They're not the ones working at the disorganized sweatshops that companies in developed nations outsource programming work to.
-
...
If all we can do is vote with our feet- quit the job at the mega corp that is making it impossible to do safe products - we have a big problem.
Imagine quitting Boeing over their scumbag ethics, and having to look for another job.
...
"... one manager saying at an all-hands meeting that Boeing didn’t need senior engineers because its products were mature. “I was shocked that in a room full of a couple hundred mostly senior engineers we were being told that we weren’t needed”.
So I don't see anything to stop engineering from being treated as a commodity, with the intangibles such as quality and safety of design having a price tag a scumbag CEO knows about.
Instead of making the corporation efficient, clear-cutting staff is Muilenburg's genius.
...
Welcome to capitalism.
-
Thank you!! I have seen multiple times where indians have been bashed up for poor quality of work, in general. I am not disagreeing nor agreeing. It just brings one question to mind.
If you(as a corporation) have had the bitter experience of burning your hand, by outsourcing to a vendor based on cost alone, and you get a piss poor quality of job. Then why do you repeat the same mistakes over and over again?
It looks like you are using outsourcing and cheap labour as an excuse and then crying hoarse about it.
Have you failed primarily as a responsible management to identify an appropriate vendor(not just cost alone) or has the vendor failed to deliver a quality product.
It looks to me like it is a cascaded failure on multiple levels. And then the "indians" get blamed for poor quality.
Again to be clear, I am not proud of what quality of work we do - especially for IT. I am more than aware that many many indian companies use quantity to average out the quality.
But it seems like many would only like a scapegoat to blame and transfer responsibility.
PS: I am an indian FWIW.
PS: @james_s I am not attacking you on your post. It just felt related to my rant.. thats all.
</rant mode off>
Quote from: james_s on Today at 02:16:30 pm (https://www.eevblog.com/forum/index.php?topic=196308.msg2518080#msg2518080)
>Quote from: blueskull on Today at 01:44:21 pm (https://www.eevblog.com/forum/index.php?topic=196308.msg2518017#msg2518017)The problem is, can anyone prove with concrete evidence that outsourced engineering is more inferior than US engineering.
In other words, how can they prove the chance of f*ing up by Indian coders is higher than US coders, or is this just a fluke.
It's not as simple as engineers in one country being superior to those in another. A significant part of the issue is that development is outsourced abroad for one reason only, and that is reduced cost. The companies that set up overseas get the job by submitting the lowest bid and they are able to submit the lowest bid by cutting every corner they can, insulated from any direct oversight by the large distance. There are loads of talented engineers in India and elsewhere but most of them get jobs at reputable companies or come to places like the USA to work. They're not the ones working at the disorganized sweatshops that companies in developed nations outsource programming work to.
-
The only solution I see is that we as engineers should put a full stop on shit like this and refuse to deliver low quality or unsafe products.
Let me express my lengthy oppinion.
Lets use the tyre example in an idealistic 0/1 world without considering probabilities and unknowns for simplicity.
An engineer has to fulfill the set of requirements in "the best way he is capable of" in a given design.
That is all of his/her obligations to the company, and society, IMHO.
The above mentioned set of requirements is just a formal list of properties the design should posses. Usually this is given in a form of a test scenarios. For example:
- load 600kg.
- speed 150km/h
- distance 100kkm ...
etc.
An engineer/designer is not responsible for preparing the set of these requirements.
If he designs above tyre based on the requirements provided and the tyre fractures at 160km/h killing someone then you cannot put a blame on an engineer for that. It might be a suicidal customer or it might be that a marketing department advertised it as 160km/h tyre - irrelevant from the point of responsibility of an engineer.
Even if a marketing department calls the project "New technology safer 160km/h design" it is irrenevant in a discussion as the marketing name or its implicit properties do not come into the set of requirements. It neither has to be "new", nor "safer" nor withstand "160km/h" and only the requiremens that state 150km/h matter, not the marketing name of final product.
Sorry to explain that as you were a child but you have to understand that the design neither is based on any public relations matters nor on moraliy but on science.
Now the best way listed above does not mean that the design that does not fulfill the good requirements is a bad design. You rarely get to the final design in one step and susually 2-3 iterations are needed and a bunch of tests to get to the ultimate goal. So If an engineer designs a tyre that at intermediate development stage fails at 140km/h tests then again this most likely means he needs to tweak some parameters of the design. Again, if that preliminary design is shipped to a production and someone dies at 150km/h, it is not a problem of a designer.
You might come to a conclusion I believe an engineer takes no responsiblity at any circumstances. If an engineer designs a product that fails the requirements tests (undershoots or overshoots) and it is evident that with the same resources given (time, budget, workforce, experience etc) it could have been possible to reach the goal but engineer just f#$%^ed up the design by being negligent, and now we have a 200km/h tyre that costs 3x as much as 150km/h should, in my oppinion s/he can be (at least morally) responsible for incurring losses, at most.
This is how you distinguish a good engineer from bad engineer and a good design from bad design.
A good engineer will hit the requirements more accurately and cheaper/faster/better than poor engineer.
It has nothing to do with safety.
-
Guys, I am surprised that nobody has posted this here yet:
https://www.pprune.org/rumours-news/623050-9-per-hour-code-boeing-jets.html (https://www.pprune.org/rumours-news/623050-9-per-hour-code-boeing-jets.html)
Quoting ThreeThreeMike from that forum:
The Yahoo article, your thread title, and your post above falsely assert that Boeing outsourced software development to employees that were paid $9 per hour.
The reference to that wage was made by a consultant who has no idea how much Boeing's subcontract employees are paid. Your careless and inaccurate pronouncement illustrates how such inflammatory claims are spread.
In short, that news article making that $9 is sensationalist BS based on wild claims by someone who has no knowledge of the matter.
While Indian coders were working on some functionality, it had nothing to do with the crashes or anything else. Also, for ex. Airbus has a far larger presence in India than Boeing - and nobody seems to be making a fuss about that.
So, please, let's put away those torches and pitchforks, sensationalist crap like this is not worth it.
-
I've read the Bloomberg article and I'm surprised that an aviation pioneer like Boeing is trying to reduce costs by moving QA responsibilities to suppliers. From a legal point of view they can point their finger towards the supplier if something goes wrong but it will also impact Boeing when customers lose faith in the quality and safety of Boeing jets. There are also reports about tools found by the airlines in new jets just delivered. Add MCAS and so on. This points to a big problem with Boeing's internal management culture which harms the company and the products.
My take on outsourcing software development is a little bit different. Condemning it is just a silly prejudice. Yes, you can make many mistakes causing the outcome to be worse than doing everything in house. And you shouldn't outsource if it doesn't make sense. Partnering with some other company requires some effort. Simply sending the system specification and looking for the lowest US$/h rate asks for a disaster.
-
Subscribing to this thread, I will post later
-
What's changing now is that previously this sort of crap was limited to business software and things like computer games, where it caused stress and suffering for the end users, but not much besides that. Now it's going full speed into mission-critical systems and disasters will happen again and again.
Because they tend to compare themselves to businesses that can operate this way or try to squeeze water out of stones to prove themselves. Once money has no physical unit attached to it, you can compare it with everything and scale freely, you don´t even need to understand the process.
Not that comparison is bad, but context matters. No one wants the scandal, but most think that it is progress to provide all factors that lead to it.
-
Functional safety standards like IEC61508 require a corporation to write up how the people are qualified to even do the project. Education, experience, training. To prove you're not Clown Co. doing a safety system.
An employer hired engineers from developing and war-torn countries. Most were found to have fake credentials after people noticed they were using google and internet forums to get answers on their work. When asked hard engineering questions, or given a little tiny test, they were clueless- so we fired them. No savings there.
India purchases weapons systems and missiles from Boeing, in exchange for setting up HCL across the street (https://www.hcltech.com/press-releases/press-releases-business/hcl-technologies-launches-center-excellence-boeing) and now the plane's software is much Bollywood.
Welcome to capitalism.
Corporate governance is a problem, having Dennis Muilenburg as both CEO and chairman.
Like Zuckerberg and Bezos, you have one person running things with no oversight. It easily derails, having a dictatorship or corporate totalitarianism calling the shots.
If you want the aircraft to have integrity, you might have to foster true engineering instead of getting Clown Co. to do the work.
-
Is engineering ethics not taught any more, I know when I was in school it was a required course, and it goes WAY beyond merely meeting the given spec the best way you know how :wtf:
Not signing off on a design because while it meets the formal spec you do not consider the spec to have covered the bases is a thing among engineers, and when engineers start abdicating that responsibility I am not at all sure I wish to call myself such.
Outsourcing as such is a read herring, and actually outsourcing the testing of software systems conformance against spec is not inherently unreasonable, but usually my experience was that conformance against spec was ALL you would get from those tests, and as is well known you cannot test quality into a product.
You do however need those tests, and it is a cheap way to get them done, but they are in no sense sufficient.
Where it fell down for us, was that the testers would test against the spec as written without applying any kind of task domain knowledge or common sense, it caught plenty of bugs, but almost no architectural issues with the bigger system (Which is where the really dangerous things tend to hide).
The other thing we found was that (And experience may differ on this) the Indian contractors we used were very good at coding to a spec as long as that spec was absolutely stable and unchanging (How many specs have you EVER seen like that?), but were really not good at coping with the reality of a steady stream of changes (often to bits of behaviour not explicitly specified). Might just have been the company we used.
I am certainly not prepared to say that outsourcing some types of testing is unreasonable, but there are things that need a higher level view that outsourcing shops will probably not have.
Regards, Dan.
-
#####PATRIOT OS 5.1#####
पैट्रियट मिसाइल (परमाणु) वैरिएंट मिसाइल लक्ष्यीकरण सॉफ्टवेयर के 5.1 संस्करण में आपका स्वागत है। सटीकता समर्थन के लिए 1 (888) 211-4727
-
Something I forgot to mention, at a former employer we tried outsourcing some of the software testing to a local firm specializing in that work. They were another American company located just a few miles away and the result was the same sort of crap people say about overseas outsourcing. I was in charge of assigning them tasks and processing the results and in the end it would have been less work for me to just do all the testing myself. It was more effort spent in overhead than we got in return and in the end I don't think they found any significant bugs that I didn't already know about. I spent a lot of time explaining how the features are supposed to work and sorting out false positives. I think that's the same everywhere, an outside company will never know the product as well as the engineers that built it and the architects that designed it. Outsourcing is often a false economy and people underestimate the amount of overhead it involves.
-
Outsourcing may not cut overall costs (and often, it's the opposite indeed), but it does cut fixed expenses (less employees for the "same" amount of work), something accountants and shareholders are fond of.
-
Outsourcing may not cut overall costs (and often, it's the opposite indeed), but it does cut fixed expenses (less employees for the "same" amount of work), something accountants and shareholders are fond of.
Sure but we had contract workers too, those are supposed to be for reducing fixed expenses. They are often abused though, being kept around for many years.
-
The idiot exec thinks it's $9/hr vs $50/hr, massive profits and love from Wall Street.
But outsourcing takes a great many more man-hours. You have a contractor that really doesn't know the work at hand, has to try learn it and in the end, it was faster and cheaper to do it in house when you review all the costs and include more time to fix deficiencies. Even including pensions and benefits.
I also found outsourcing terrible for the extra overhead.
Writing up requirements documents, meetings, supervising the contractor, communications, answering questions etc. takes up so much time. A total waste of in-house expertise.
The final insult is the work received is low quality compared to what in-house teams can dish out, and the invoices are astronomical because at $9/hr it's overlooked that there was 20X the man hours burned up.
I would say its a myth that you will save money outsourcing engineering of any complexity.
-
Am not sure, is the problem that those engineers are only payed 9$ OR that maybe Boeing did not audited their contractor to be sure that it meet the requirement needed to develop mission critical software. Am sure that it's not safe to assume that the 9$ engineers are less competent then 90$ Engineers, with an obvious pointing to Indian Engineers and Russian Engineers. In no country the hour rate of an engineer is a direct image of the talent or competence, it's more about the local economy. 9$/hour engineers don't have to be recently graduate engineers too, they can be experienced. Let's not forget that the FAA is the one who have the final word on if an airplane can or can't take the air (and i far as am following this story they did outsource some of the required tests to Boeing it self) am going to guess that FAA engineers don't have 9$ hour rate, still ... :palm: Am all for business hiring local talents or outsourcing to domestic contractor what ever the country is, it helps to maintain a healthy local economy but I think someone is trying to make benefit out of such story :bullshit:.
-
Outsourcing may not cut overall costs (and often, it's the opposite indeed), but it does cut fixed expenses (less employees for the "same" amount of work), something accountants and shareholders are fond of.
Sure but we had contract workers too, those are supposed to be for reducing fixed expenses. They are often abused though, being kept around for many years.
Yes, contract workers are used liberally as well. I can tell you Airbus uses MANY contract workers. That works better than outsourcing, but they never really feel part of the company, which has consequences.
I suppose that one big difference (at least in the eyes of upper management) is that contract workers require middle management - which itself is a fixed expense - whereas pure outsourcing doesn't (at least in theory). Reality of course is different. It also doesn't require more work space and equipment, other fixed expenses.
Now outsourcing can take different forms. In the aerospace and automotive industries, a lot of subsystems are purchased, either off-the-shelf or 100% custom developments, from specialized companies. This kind of makes sense, and is pretty different from outsourcing projects using general-purpose engineering services based in India.
-
The idiot exec thinks it's $9/hr vs $50/hr, massive profits and love from Wall Street.
But outsourcing takes a great many more man-hours. You have a contractor that really doesn't know the work at hand, has to try learn it and in the end, it was faster and cheaper to do it in house when you review all the costs and include more time to fix deficiencies. Even including pensions and benefits.
I also found outsourcing terrible for the extra overhead.
Writing up requirements documents, meetings, supervising the contractor, communications, answering questions etc. takes up so much time. A total waste of in-house expertise.
The final insult is the work received is low quality compared to what in-house teams can dish out, and the invoices are astronomical because at $9/hr it's overlooked that there was 20X the man hours burned up.
I would say its a myth that you will save money outsourcing engineering of any complexity.
This.
There are so many things not done properly when implementing outsourcing, that even if the chosen company is reputable and good, the result will be poor. When we outsourced a major inventory creation program back in 2005 we were given a questionnaire to fill out; the stated purpose was to determine whether an application could be legitimately outsourced or not. Several of the critical questions involved privacy and customer personal data, and a "yes" to any of them was said to be a no-go for outsourcing. We answered "yes" to several of them and I commented to a manager that this would be a show-stopper for our software. He replied "That's OK, they're going ahead with it anyway." It was just another manager check-box, not a real concern.
We had unending problems with the first contractor (after shipping all the documentation to them, they were supposed to be trained by their lead developers, not us). They had no clue how the software worked, constantly peppered us with questions, and repeatedly shipped broken software to meet deadlines. So we switched contractors (we developers had no input into the selection process) and had a repeat of the first scenario. Finally we found someone who could get the job done efficiently and accurately, but they cost too much and we switched from them to an American-owned company which was cheaper (because all their development was done in third-world countries). Of course, we were forbidden to maintain a contract beyond 18 months, because that might lead to the developers becoming familiar with the system and the company raising the prices accordingly. When I left that project, it was months behind schedule and with a bug list that increased pretty much every day.
In every project where I was involved, big words were spoken and always followed by cost-cutting, excuses and customer dissatisfaction. The one project we were given to do locally was estimated by someone who was only vaguely familiar with the software and then given to us. It was drastically underestimated, and we said so at the beginning. Never mind, we were told, just do it. My rating on that program was pretty low because I took the time to do it right, check the results and fix the problems, costing us extra money (which should have been estimated in the first place). My sole defense is that it was almost completely bug-free and the customer was delighted. It was, incidentally, a system used to track phone usage and was a major source of data for planning and coordinating inventory. I suspect part of the reason it was given to us was that there were zero specifications, only the output of an outmoded and slow product which needed replacing.
It's all about money, no matter what the bosses say. I know a major telecommunications company which "outsourced" all the databases which contain line, switching and trunking details for the continental US so that they are now owned by two European companies. The cost savings were twofold: the company no longer had to maintain all its US-based customer data, and bug fixes/expenditures were forestalled by quoting a $1M minimum contract to fix anything. I may or may not have worked for this company and gotten the info directly from the database managers involved. >:D
-
I've seen 9 USD/hour student workers being absolute geniuses and solving impossibly looking problems. I've also seen people earning somewhere 150 EUR/hour being absolutely useless at their jobs, to the point, when I was actually asking "What the hell did they even accomplish since they are here?". Yes, and I had Indian colleagues, who were very good at their programming job. I've also seen someone with a gardening degree set up and keep a PCBA production line working for years. And other engineer with "decades of experience, you should be lucky that I'm willing to work with you" making idiotic decisions, and getting booted job after 2 months of doing practically nothing.
I dont think think this post has a point. Or the article.
-
Consumer electronics has always been a cut throat business, and everything possible was done to lower costs.
But everyone understood that there were certain engineering sacred cows, where the cost, although very important, was secondary to performance and/or reliability.
One of such sacred cows were the aerospace applications. That aerospace has now fallen to the the level of consumer electronics, is a perfect example of the failure of "quarterly-stock-price-only" capitalism.
-
try taking a look at the starlink website applications.
all of it is low cost aerospace. it says so in the job postings. that is liable to turn into the movie 'gravity'
-
Is engineering ethics not taught any more, I know when I was in school it was a required course, and it goes WAY beyond merely meeting the given spec the best way you know how :wtf:
I cannot imagine ethics in software development.
This concept is totally un-scaleable.
Imagine you have a complex software development, you divide it into zillion of work packages and each work package includes hundreds of smaller tasks. Plus some external dependencies. How the hell would you like to design that with ethics in mind? How to formalize ethics and how to test ethics?
This can ONLY be scaleable when you a-priori assume the development does not require ethical engineers to develop that.
If the requirement says the software should work from Monday to Saturday, I implement Monday to Saturday. It is NOT my problem what happens on Sundays and I am not spending any time on implementing or testing Sundays. I do not deliver what I was not assigned to. I expect my boss to align me if I attempt to introduce anarchy and starting my own competing "management department".
Of course I might ask myself "wht happened with Sundays". Most likely I got Monday to Saturday and someone else got Sundays to implement because Sundays require much different implementation. Or maybe no, we do not implement Sundays at all and if the plane flies on Sunday - oops, BSOD. Not my problem.
Not signing off on a design because while it meets the formal spec you do not consider the spec to have covered the bases is a thing among engineers, and when engineers start abdicating that responsibility I am not at all sure I wish to call myself such.
The problem if the requirements cover Sundays or not is not a problem of an engineer that does implementation. It is a problem of some higher level managing. The responsibility of an engineer is ony limited to the requirements IMHO and not to the lives lost if the requirements are stupid or incomplete.
Do I as an engineer feel responsible when someone dies because of the product of my company?
Buaaaahhahaha.
Do shareholders of Boeing feel responsible for MAXes?
Buaaaahhahaha.
I think you meant ethics in stock market.
Because ultimately not engineers but shareholders (indirectly) decide about EVEYTHING the company does.
-
Although I empathize with your pain Brutte, in the real world one as an engineer is still required to determine fail-safe solutions to people's stupidity or malice.
A simplified example: let's say someone is driving at fast highways speeds, angrily discussing with his/her significant other and decides to shift the transmission into reverse. Just to scare the sh!t out of the passenger.
The transmission's software should flag this as an invalid command, and either fully ignore it or default into a safe condition, i.e. neutral.
If it does not, and the resulting mayhem provokes casualties and/or physical damage, I am sure that the auto company and most likely the transmission company, will get their asses sued.
-
What would have happened in the days of a fully manual or hydraulics-only automatic? Does a carmaker have an unending obligation to introduce safety code into a transmission just because of partial electronic monitoring/control?
-
Is engineering ethics not taught any more, I know when I was in school it was a required course, and it goes WAY beyond merely meeting the given spec the best way you know how :wtf:
I cannot imagine ethics in software development.
This concept is totally un-scaleable.
Imagine you have a complex software development, you divide it into zillion of work packages and each work package includes hundreds of smaller tasks. Plus some external dependencies. How the hell would you like to design that with ethics in mind? How to formalize ethics and how to test ethics?
This can ONLY be scaleable when you a-priori assume the development does not require ethical engineers to develop that.
If the requirement says the software should work from Monday to Saturday, I implement Monday to Saturday. It is NOT my problem what happens on Sundays and I am not spending any time on implementing or testing Sundays. I do not deliver what I was not assigned to. I expect my boss to align me if I attempt to introduce anarchy and starting my own competing "management department".
Of course I might ask myself "wht happened with Sundays". Most likely I got Monday to Saturday and someone else got Sundays to implement because Sundays require much different implementation. Or maybe no, we do not implement Sundays at all and if the plane flies on Sunday - oops, BSOD. Not my problem.
Not signing off on a design because while it meets the formal spec you do not consider the spec to have covered the bases is a thing among engineers, and when engineers start abdicating that responsibility I am not at all sure I wish to call myself such.
The problem if the requirements cover Sundays or not is not a problem of an engineer that does implementation. It is a problem of some higher level managing. The responsibility of an engineer is ony limited to the requirements IMHO and not to the lives lost if the requirements are stupid or incomplete.
. . .
Well, that is an interesting example--even if you are *only* responsible for weekdays, you *do* have the problem of the Sunday to Monday interfacetransition. So, if this is some continuous process then it seems obvious that we cannot have totally different assumptions based on day-of-week. So, yeah, your attitude is correct, perhaps, but testing is a b*tch.
In the case of Boeing the basic problem always seems to come down to their assumption that making a new type 737 should be "cheap" just because it is a so-slight modification to an existing tried-and-true design. Wrong. Wrong. Wrong. They seemed to have made this assumption at the very beginning but then chosen aerodynamic characteristics totally at odds with that assumption.
Epic fail.
-
Although I empathize with your pain Brutte, in the real world one as an engineer is still required to determine fail-safe solutions to people's stupidity or malice.
A simplified example: let's say someone is driving at fast highways speeds, angrily discussing with his/her significant other and decides to shift the transmission into reverse. Just to scare the sh!t out of the passenger.
The transmission's software should flag this as an invalid command, and either fully ignore it or default into a safe condition, i.e. neutral.
If it does not, and the resulting mayhem provokes casualties and/or physical damage, I am sure that the auto company and most likely the transmission company, will get their asses sued.
Why should it? Everybody should know not to shift a transmission into reverse while the car is in forward motion. I have never had a vehicle that had any sort of feature to prevent this and it has never been a problem.
I mean what if someone decides to angrily slam on the brakes in the middle of a busy highway? Does the car have an obligation to flag this as invalid and refuse to engage the brakes? I don't think so. Part of driving a car is knowing how to properly operate the machine in a safe manner.
-
This can ONLY be scaleable when you a-priori assume the development does not require ethical engineers to develop that.
Then you are scaling these systems past the ability to Engineer them, don't do that until you have the conceptual tools to be able to do the work right.
When I studied EE, we had Therac-25 as the posterchild for engineering done wrong (Software, also the decision to make it open loop), together with the Hyatt Regency Disaster for structural done wrong, and a whole raft of railway cockups (From which the industry did actually learn, railway signal interlocking is fascinating victorian Engineering (They even had a train crash due to a race condition)). I suppose now you would add the challenger disaster (Several lessons to be had there).
The willingness to throw complex systems together without the ability to fully reason about them (And their failure modes), and then to keep repeating the same basic cockups, is why only software developers consider "software engineering" to be an engineering discipline (Everyone else thinks they are jumped up members of the typing pool :P).
Seriously, ethics seldom gives real answers, one can debate the trolley problem until blue in the face, but eventually you have to make the call, it can however give you some tools to make that call somewhat informed.
Hell there is an attempt being made to get ethics taught as part of the MATHEMATICS degree curriculum, because you know someone innocently going for a fields medal by publishing a solution to the discrete log problem or publishing a log N fast prime factorisation over a finite field would kind of break civilisation (By basically destroying the underpinnings of the crypto used to secure finance).
Engineers take responsibility for the systems they produce, A civil does not get to walk away unquestioned when the dam bursts because the interface between the concrete and the rock didn't work quite right, the power plant guys gets hard questions when that steam bubble revels a large positive void coefficient in part of the core, the railway signalman gets AUTOMATICALLY charged with manslaughter if there is a coming together of two trains [1].
Regards, Dan.
[1] That interlocking thing again, in the early days the signal men objected because they thought they knew better then the room full of cams and gears where the trains were, so a big red key was added that could override the interlocks.... Turns out that in short order most train crashes featured the use of that big red key, so in the UK the practise became to automatically charge any signalman in charge when there was a train crash due to conflicting signals or points.
This discouraged the use of the big red key without sending people to physically check, and the crashes stopped almost overnight. Note that charge is not the same as prosecute is not the same as convict, there was felt to be a case to answer, but if you could answer it then fine.
-
...
Engineers take responsibility for the systems they produce
...
They may, but rarely do they have authority over specifications, scheduling, and budgets.
-
The responsibility of an engineer is ony limited to the requirements IMHO and not to the lives lost if the requirements are stupid or incomplete.
You are describing a typist not an Engineer.
Requirements documents are essentially ALWAYS incomplete, so you need to get the bigger picture to be able to even recognise where the blanks are.
Sunday? In what timezone? What happens in the transition? What happens when crossing the international date line (This one has actually caused real problems with Aircraft!)? What about the OTHER way? Lots of questions, even if I have established that someone else is doing Sundays....
You better believe I will go and find that architect or PM and ask questions, and that I am quite capable of going as high as I must to get answers before that code gets written or that circuit designed.
Kipling had the right of it in the "Sons of Martha", we check, we test, we don't assume, and 'It'l be right' is not an appropriate attitude for any kind of engineer anywhere safety might matter.
We may not have the authority over specs, schedules and budgets but we can say "No", cost me a job once, but if your bosses boss is not listening to the expert, do you really want the responsibility!
Regards, Dan.
-
...
Engineers take responsibility for the systems they produce
...
They may, but rarely do they have authority over specifications, scheduling, and budgets.
Engineers have full authority of denying the design. They have the most authority. A manager has never managed to get a product out without the engineers.
Worst thing that can happen is to lose your job.
Well worth it, to have clear conscience, and to sleep well. You'll always find something else to do. Contrary to the popular misbelief, losing your job is no biggie. Unless you artifically design your own life so that it becomes a biggie. This is the root cause of the issue - as an engineer you should prefer root cause analysis, and start re-engineering your life so that you can afford losing the job if it needs to be that way.
Bonus points: make the whistleblowing as public as you can. If you succeed, it can force them to correct the design, instead of finding a new ape to perform the manslaughter. Although I do understand that this can get really messy, and may put your personal safety in danger. Hence "bonus points", not expecting everyone to go full public with the matters.
If more of us wouldn't be fucking cowards, then we wouldn't even lose our jobs because we would have some power of masses behind us. Not expecting this would happen, though. We'll continue being selfish cowards. The engineer wants to have his hybrid Toyota, just like their manager wants to have their BMW, and their boss needs their Ferrari.
An engineer who chooses to get paid instead of designing a safe system, is absolutely no different from a manager who chooses to get paid instead of designing a safe system.
Everybody's in the chain is at fault, equally. Everybody made an explicit choice of purposedly killing people in order to have a nice car.
Yet we at the "lower end" of the chain love the idea that we were somehow forced to do what we did. But factually, our bosses and their bosses were equally "forced", by the very same social norms and constructs.
In fact, sometimes the "low end" is the worst. The engineer almost always knows about the shit that's going on. The closest boss should know. Their boss likely should have an idea. But really, it's well possible that the engineer just keeps his mouth shut by fearing that he's not being taken seriously anyway. While probably completely right, this is no excuse. You have to try.
-
You are way off.
Expecting the engineer to be the lone one with integrity in a corporate environment of corruption - executives, project managers, manufacturing, accountants etc. is absurd.
Projects are months or years long and involve many people. Thinking the engineer oversees the whole chain, every link on the design is unrealistic on large projects. The best engineers cannot design and build quality, safety when they're in a sick, corrupt environment with no support.
Whistleblowing, now that you're unemployed due to having integrity and walking out, multi-billion $ Evil Co. goes after you with a lawsuit and can you finance that? A wife and kids worried about money, and you are fending off mega lawyers who can squish you like a bug. Wow engineering is a great profession, surely my whistle blow will be heard by the world and something great will change. Oh and that clause in the original employment agreement telling you to shut up or else...
Blame the engineer, always blame the engineer.
I'm seeing a lot of sociopaths climb the corporate ladder and use their iron fist to destroy any ethics or values, all for power and profit. The mob has the same mission.
Corporate policing is a problem, the highest priority is maximum profit as quickly as possible, while eluding laws for tax, export, environment, safety and regulatory.
Since engineers deal with reality - physics, electrons etc. we have to be honest in order to be any good, at the technical level. But reducing us to toy soldiers and expecting us to change the war?
Everyday google, facebook, reddit, twitter, microsoft software engineers go to work and write code to mine your private data and exchange it with third parties and affiliates, for profit. Do they walk out the door? The CEO would still be enjoying caviar on his yacht.
-
You are way off.
No I'm not. I'm oversimplifying a complex matter (on purpose), but I think it's an important aspect, and I don't hear this side too often, which is why I wrote what I wrote.
Expecting the engineer to be the lone one with integrity in a corporate environment of corruption - executives, project managers, manufacturing, accountants etc. is absurd.
Exactly. What was I saying about the bosses being in a similar situation themselves?
You are not alone. You are only alone because you think you are.
Projects are months or years long and involve many people. Thinking the engineer oversees the whole chain, every link on the design is unrealistic on large projects. The best engineers cannot design and build quality, safety when they're in a sick, corrupt environment with no support.
I agree, but I didn't say anything to contradict this.
If you know you are committing an atrocious thing, then you have full authority to stop it from happening by your hands. The more people realized this, the more effective it would be. It's not an excuse that they'll hire another one to perform it.
And not all managers/investors/etc. are psychopaths. If a certain division has an alarming quit rate of experienced design engineers, some of who are brave enough to generate a few internal reports of what's happening, it's well possible that the situation is rectified. An engineer being a small cog doesn't mean they are meaningless, replacable machines. Good high-level managers up the ladder, yes they do exist as well, know this very well, but are hindered by the communication break.
Whistleblowing, now that you're unemployed due to having integrity and walking out, multi-billion $ Evil Co. goes after you with a lawsuit and can you finance that? A wife and kids worried about money, and you are fending off mega lawyers who can squish you like a bug.
Which is exactly what I was talking about:
I do understand that this can get really messy, and may put your personal safety in danger. ... not expecting everyone to go full public with the matters.
Yet, I have a huge respect for those who make the decision, putting their well-being, physical included, in danger while exposing such things.
I'm seeing a lot of sociopaths climb the corporate ladder and use their iron fist to destroy any ethics or values, all for power and profit.
The higher at the ladder, the higher the chances they are full-blown sociopaths and couldn't care less about the wellbeing of others.
OTOH, number of such positions is lower, as well. The low-level engineers have to work in masses to make it happen. The psychopaths really need these easy-to-manipulate people to perform. But if you have to work in an environment where you are scared about being fired, you have already lost. It's mentally so distracting that it's probably a wise choice to redesign your life principles, and get a better job, even if it takes time, or seems to pay less (initially). BTW, really competent people are, I think, more likely to do this. Psychologically ill workplaces end up reducing in quality of their personel. It's a slow process, but finally it leads to financial problems and probably the company going under. (This doesn't apply to companies which specifically do immoral business on purpose, like Facebook or Microsoft: they get the kind of people they need, and it's only good for them if they get rid of the emphatetic ones. Their technical quality gets lower and lower, but it doesn't matter, they are not competiting with it.)
But reducing us to toy soldiers and expecting us to change the war?
That's exactly what the sociopath managers are doing, and they do it regardless of what you think. By allowing it to happen to yourself, then cry in the corner that "I was used, it wasn't my fault, it wasn't my fault", is exactly what they want. They have completely won. They will remain anonymous, faceless symbols of the "broken process" that caused the failure. But guess what? Being sociopaths, they couldn't care less. Personally they survived, and are laughing all the way to the bank, and their yachts. While you, as an engineer who was a real part of the process, have problems sleeping at night knowing that you, maybe, after all, might have been able to do something about it.
Everyday google, facebook, reddit, twitter, microsoft software engineers go to work and write code to mine your private data and exchange it with third parties and affiliates, for profit. Do they walk out the door?
You seem to assume that a Google, Facebook, or Microsoft engineer would be an emphatetic person caring about the privacy of the others, comparable to one who is designing safety systems for an airplane. While this might be true in some individuals, I would think that most people looking for a job at Facebook know exactly what kind of job they are going to do, and have a moral agreement with their sociopath bosses.
I think whistleblowers from such corporations create a good story though, along the lines of "I was doing the immoral thing from the beginning, as I knew I would, but one day my consciousness totally snapped". These are stories of ex-kinda-maybe-psychopaths healing and trying to make up for their own wrongdoings, not to expose a problem of a corporate culture everybody knows about already. Think about Snowden for example.
-
That's mostly the software industry, and is why I have a lot of trouble considering it engineering rather then the negative side of H.S. Thompsons 'cruel and shallow money trench'.
Nobody said taking that decision to face down the boss is easy, or that it doesn't have a cost (I was unemployed for about 6 months after walking out on those clowns), but there are places to cut corners and places not to.
If engineering is a Profession then surely professional standards should apply, including reasonable professional ethics with a responsibility to the public that uses, travels in, is treated by, and sometimes walks on or under our designs? And yes, that includes a responsibility to make sure as far as we can that the systems we work on the design of are safe (You won't always succeed).
There is probably a reason I lasted less then a year doing automotive software (And most of it was not even anything higher then SIL 3).
I expect the engineer to get a gig in a shop that doesn't suck if the company is that bent out of shape, it usually is not that hard to find a gig that at least keeps the bullshit to the boardroom and stock price games and away from anything that matters.
Regards, Dan.
-
I dont think think this post has a point. Or the article.
Its interesting information though, if true.
Some other info:
- The average hourly wage in India is $1.40.
- Median wage for a developer is $208 USD per month (which is approx $1.30/hr), engineer is almost the same.
So they were being paid about 7x the typical wage for that position. I would imagine they would have to be decent devs to get that rate.
Of course there are downsides mentioned here which can't really be avoided (time zone, english skill, etc.).
http://www.salaryexplorer.com/salary-survey.php?loc=100&loctype=1 (http://www.salaryexplorer.com/salary-survey.php?loc=100&loctype=1)
-
Its interesting information though, if true.
Some other info:
- The average hourly wage in India is $1.40.
- Median wage for a developer is $208 USD per month (which is approx $1.30/hr), engineer is almost the same.
So they were being paid about 7x the typical wage for that position. I would imagine they would have to be decent devs to get that rate.
Of course there are downsides mentioned here which can't really be avoided (time zone, english skill, etc.).
http://www.salaryexplorer.com/salary-survey.php?loc=100&loctype=1 (http://www.salaryexplorer.com/salary-survey.php?loc=100&loctype=1)
Based on my actual payroll in India, the figures above [at least for software engineers] are complete crap. These figures are closer (but still well short of what my teams over there are making by about a factor of 2): https://www.payscale.com/research/IN/Job=Senior_Software_Engineer/Salary (https://www.payscale.com/research/IN/Job=Senior_Software_Engineer/Salary)
I have 21 employees working for me in India. Of the 21, I don't have a single software engineer (even a level 1 fresh college graduate) making less than 10 Lakh (a million) INR (~$15K) and several of the more senior folks are making a significant multiple of that.
I have no idea where the site you cited got their figures, but they're wildly off the market rates, IME.
-
You are way off.
No I'm not. I'm oversimplifying a complex matter (on purpose), but I think it's an important aspect, and I don't hear this side too often, which is why I wrote what I wrote.
I'm not seeing a solution other than "vote with your feet".
It's career suicide in many ways. There are few, if any employers in industries such as aviation and automotive in some countries/regions. Engineering gets specialized so career hops can be tough.
Job interview: "So you left Boeing?"
"Yes, they specialize in engineering death machines"
"Uhhhh"
"I left because their business ethics are corrupt"
"But they have $205 billion market cap and buy from us"
...Mighty Mouse does not get hired.
Other professions can't kill people en mass like engineering.
This whole debacle will just keep repeating, there's nothing to fix it :-//
-
Job interview: "So you left Boeing?"
"Yes, they specialize in engineering death machines"
"Uhhhh"
"I left because their business ethics are corrupt"
"But they have $205 billion market cap and buy from us"
...Mighty Mouse does not get hired.
You don't have to put it exactly that way.
You can pull it off as being a really experienced safety analyst, if you wish. Of course, you are not going to get hired to another piece of shit corporate culture where safety is a swear word and where you would be another replaceable cog. But why would you want to?
I don't understand the idea of needing to get hired to a particular type of job at any price. The world is full of opportunities and jobs where you don't need to compromise your integrity. You can build one for yourself if everything else fails.
Other professions can't kill people en mass like engineering.
Oh, there are many:
* Airline pilots
* Bus drivers
* Soldiers
* Politicians and lawyers (indirectly)
-
Other professions can't kill people en mass like engineering.
Yeah, there are many others.
Besides, that's what verification and validation processes are for. A design fuck-up should ideally not compromise safety, as it's supposed to be caught during V&V.
Of course no process is perfect, but that's still a lot more than what is done with many other safety-critical professions.
-
And that said, I agree with the fact that storming out of a reputable company claiming that they are shit at doing things properly is a huge professional risk. Nobody is going to take you seriously unless 1/ dozens of other engineers do the same, 2/ there is no evidence that those people were led by one (then it's easy to find something wrong with this bad guy), and 3/ you have a solid file proving what you claim and a very good lawyer. Then if you do, I suggest you pay for some personal protection.
-
A design fuck-up should ideally not compromise safety, as it's supposed to be caught during V&V.
Exactly, and the whole verification thing is completely based on the employees speaking up, including showing whenever an automated test procedure is fundamentally flawed and can't pick up an obvious issue. If that vital part of the verification process is missing, then it will become just an automated report generation business, run by the management to minimize "hassle".
Verification needs to be done for specifications, as well. If you only verify whether the implementation reproduces the specification, you have done exactly nothing to prove the safety of the system.
Human factor is very much needed in finding these flaws, and the process needs to have a way to report and discuss the concerns. Otherwise, it's not a verification process.
But almost never it's about a single person being responsible. The atrocities tend to go through many hands, any of which could react to the situation, in many different ways, some very productive and supported by the system.
Losing the job and "looking bad on CV" is the worst case scenario. No, actually it isn't. The worst case scenario which actually does happen, is that you don't speak up, hundreds of people get killed, and your self-consciousness won't let you sleep properly, and you commit a suicide and leave your wife and kids in unlimited grief.
-
The US navy has a couple of interesting verification programs, thinking of their directorate of reactor safety and the "Subsafe" program.
Basically neither organisation answers to the operational chain of command, so there is no conflict of interest at the sharp end between reporting issues (and putting a hold on work) and needing to deploy the ship.
Rickover had the right of it, but difficult to make that sort of thing work in the context of a company.
Regards, Dan.
-
They sold 5000 of the 737 MAX you think there would be money for high paid software engineers?
Why would they do that when they can cut and paste from StackExchange?
(https://media.giphy.com/media/3oEjHAUOqG3lSS0f1C/giphy.gif)
-
A design fuck-up should ideally not compromise safety, as it's supposed to be caught during V&V.
Verification needs to be done for specifications, as well. If you only verify whether the implementation reproduces the specification, you have done exactly nothing to prove the safety of the system.
Well, not everyone quite agrees on definitions, but that's where I draw the line between verification and validation.
Basically, in the verification stage, you check that the system behaves according to the specs. Nothing less, nothing more.
In the validation stage, you check that the system behaves correctly in all its intended uses. That includes checking that the specs meet this goal, among many other things.
The validation stage is every bit as important as the verification stage, and even more so IMO. And it's the stage that is most often reduced to the minimum, because it can be very long, very costly and there is not much that can be done to automate it.
But almost never it's about a single person being responsible.
That's for sure. And it should never be. Otherwise the company is severly messed up.
Losing the job and "looking bad on CV" is the worst case scenario. No, actually it isn't. The worst case scenario which actually does happen, is that you don't speak up, hundreds of people get killed, and your self-consciousness won't let you sleep properly, and you commit a suicide and leave your wife and kids in unlimited grief.
That's morally true, but the reality of life in a big company is a bit different. If you work as a dev engineer and not as a V&V one, you may not even be functionally "qualified" to speak up, as it would basically not be your job, so doing that may help you sleep but it's likely not to change a thing in the general outcome...
-
The responsibility of an engineer is ony limited to the requirements IMHO and not to the lives lost if the requirements are stupid or incomplete.
You are describing a typist not an Engineer.
Typist is someone copying information, I think.
Using your analogy - an engineer would be someone closer to a translator. The source and the destination have to be 1:1 as close as possible (without adding personal remarks) but the level of abstraction is much different.
I do "translate" the requirements into the lines of code.
Also, I take no responsibility in what I am actually "translating". I am not even responsible if my translation matches the original==requirements. I hope that is verified by a reviewer and then testers once I am finished (but that is also beyond my scope and I cannot be certain as I am in EU and testing is in India). My responsibilities are limited to "translating the best I can" but I cannot guarantee the original text is not a fairy tale, if anyone is going to review that translation, etc.
Requirements documents are essentially ALWAYS incomplete, so you need to get the bigger picture to be able to even recognise where the blanks are.
Well, I am writing this from the point of view of the software developer. A job of a requirements engineer or a project manager are some other jobs that I have no idea about. This is scaleable.
The "bigger picture" you describe is not scaleable I am afraid. At least I have never heard about scaling a "bigger picture". So if you had a team of 10 developers that all do have "bigger picture" but the development would take 370 years, how many engineers do you need to do that in a year, still keeping everyone have the "bigger picture"?
If the requirements for the software developer are incomplete then you'd better take another flight.
Sunday? In what timezone? What happens in the transition?
Sure, but this can only happen if there are requirements that necessitate implementing transitions.
No requirements on transitions - no code on transtions and no test on transtions.
You better believe I will go and find that architect or PM and ask questions, and that I am quite capable of going as high as I must to get answers before that code gets written or that circuit designed.
:bullshit:
The requirements are clear. Monday to Saturday. There is nothing I coud ask about in here and definitely it is not a software developer's job to fix incomplete requirements if that is indeed the case.
These requirements were created by someone higher in corporate structure, an architect most likely, and that architect has a superior whose only job is to make sure the architect and his team does his job correctly. What you propose is to implicitly do the duties of that superior of an architect!
That is a spaghetti structure.
Not scaleable.
-
The requirements and testing were already corrupted before the work was even started. Anything to avoid triggering re-certification and keep the grandfather loopholes working.
It's a common way to sneak around safety by underclassifying the system in the hazard analysis i.e. "MCAS is not a safety critical system, there's no need for redundancy, pilot can bypass it" etc.
I imagine DO-178 (https://en.wikipedia.org/wiki/DO-178C) is about the software requirements and design, but upstream is the safety and hazard analysis which I think Boeing corrupted. So the S/W development was simplified, it could be done by Clown Co. and was not subject to any critical assessment.
-
It's a common way to sneak around safety by underclassifying the system
Exactly this happens.
It can be said that too ambitious safety standards (especially if they are just very bureaucratically strict, but not very well thought out) work against safety, because no matter what we want to believe, any design will go functionality and sales first. People want to travel -> they are given the low-cost service of travelling. Safety standards are lobbied, and whenever lobbying fails or is too slow, sneaking around utilizing grey areas, or outright illegally, is naturally done, it's human nature.
I do have a feeling that the airline safety could actually be improved by giving a bit more freedom on how the safety is implemented, concentrating on the ideas and results instead of the amount of paperwork only. Not saying paperwork isn't important, it's crucial. But it's a problem if you can document a clearly self-destructing, dangerous system and be OK with it, without a need to fix it. Happens all the time. It's a problem if fixing anything is prohibitively expensive and slow, and thus being avoided as long as possible.
As it stands out, utter fiascos* can go through the current system just fine, but if they wanted to, for example, to install a $10 CCTV camera so they could take a look at the engines or landing gear lock mechanism, improving safety in a simple way, this would require about 20 years of certification after which they could finally install a 20-year old camera that costs $10000 a piece. A slightly exaggerated case, but not by much. For example, looking at the analysis of 2013 Boing Dreamliner li-ion fires, it became apparent they were practically using the li-ion technology from early 1990's, with no modern cell-level safety features, with energy densities almost on the same level with Ni-MH (around 80Wh/kg IIRC?), but in the aerospace terms, this was the newest "high-tech", and it was old enough to be allowed on-board. Old is safe, period. Doesn't matter if the actual safety is lacking. Age and paperwork match the expected pattern. They assessed the safety of the tech based on the fact that the manufacturer (GS Yuasa, who's not well known for lithium ion products) had manufactured 10000 such cells, ever, and none of these had vented, so they thought this is a good track record. Just 10000! The cells were also specified in test procedures to literally produce an actual fire when just overcharged - none of the consumer cells at the same time had this behavior. Using modern consumer technology, the battery pack would have been two times smaller, possibly with lower thermal runaway energy, with better cell-level safety, and could have been easily equipped with secondary fire mitigation (due to a lot smaller cell size and weight) - for example, simple physical separation to prevent cascading of the failure.
*) Such fiascos as a fault in autothrottle that silently turns left engine to idle randomly near takeoff or landing, which is a sensitive phase of flight - no problem, just instruct every captain to physically block the lever using their hands when they expect it would happen - no need for an urgent fix, no need for groundings. Things like this pop up all the time, most go with little attention; while some like the MCAS get a huge attention for some time, then is forgotten by the public.
Edit: added details regarding Dreamliner battery fires.
-
Don't knock IT professionals in India. I got a call from a nice man from the Microsoft Help Desk and he knew everything there is to know about these newfangled computer things. He was able to track down a virus on the computer my grandson had given me that was infecting the whole internet. After telling me how to download some software called Team Viewer, he took over the computer for me and even took the $250 payment (including the pensioner's discount :-+) from my bank account without me having to worry about it. It only took him 10 minutes. He kindly offered to call back to check on the health of my computer and look for viruses on a regular basis. Excellent service from Microsoft and their Help Desk Professionals in India! I am going to write to that lovely man who start it all, someone named Gates, and recommend he asks his experts from the Microsoft Help Desk fix the aeroplane's problems, because they find problems the customers are unaware of and fix them up good and proper.
-
:-DD ;D
Very well played, sir! :clap:
-
ROFL, excellent :-DD
Regards, Dan.
-
Microsoft VP Julia Liuson says the worldwide shortage of software engineers will be one million in the next five years. It's just terrible they can't find anyone who knows how to code.
Boeing even tried to help, freeing up hundreds of S/W engineers to go work for them. There's far fewer blue screens nowadays at Microsoft.
Boeing was forced to charge $80,000 for the AoA disagree light to compensate for the shortage of engineers.
If only there was a way to lower wages and the standard of living, to encourage more people to become software engineers, for the good of humanity.
-
If only there was a way to lower wages and the standard of living, to encourage more people to become software engineers, for the good of humanity.
How do you expect that lowering wages will encourage more people to choose software as a career?
-
If only there was a way to lower wages and the standard of living, to encourage more people to become software engineers, for the good of humanity.
How do you expect that lowering wages will encourage more people to choose software as a career?
I guess that was sarcasms, as software engineers are already among the highest paid engineeers...
-
Lowering wages obviously discourages people to choose software as a career in countries where they have a choice (ie. where they can find other jobs that are better paid and/or are more "fun" or at least less stressful, etc.)
OTOH, it does mechanically encourage people from poorer countries to choose this path (in a globalized world, those low wages slowly become the reference wages for this kind of jobs, and they are going to be attractive only to people from emerging countries...)
We are probably only at the very beginning of this trend (even though it already looks like it's getting bad). Companies in rich countries still hire a significant number of well-paid, local engineers. I'm not sure this is going to last forever, unless the difference in the average wages worldwide shrinks, which may or may not happen. And if it does, I suspect it will be some kind of levelling down. If anyone thinks that, in a few decades from now, 10 billion people can all live like americans - that sounds funnily delusional.
-
The value that a software engineering team can create is a substantial multiple of their cost, even at FAANG-level wages. The competition at the top of most fields of software engineering is over speed/agility not dollars. If you can shave a month off getting a feature into production or react more quickly to consumer behavior, you'll prefer that over shaving 20% of engineer wages.
That may change slightly over time, but so long as there's a massive multiple in ROI terms and speed and agility matters, having people in the same time zone (or with significant overlap in working hours anyway) is going to keep software wages high for top developers in the US.
-
It's the supply and demand curve applied to labour. The more engineers the better for economic development. Governments and corporations want them by the zillions.
But the shortage of engineers is a myth, there's no shortage - it's that corporations want them cheap. They go to the cheapest labour developing nations, abuse the H-1B Visa (https://en.wikipedia.org/wiki/H-1B_visa) cry wolf and complain "can't find no S/W engineers", get grants, funding etc. to bring in the masses that can't really write code and have fake credentials. The more supply, the lower the market price.
Just ask a recent grad how it's going paying off their student loan, if it was worth it getting a degree. Local talent is ignored and struggling to get a job.
Supply is carefully controlled for physicians and surgeons. How many are admitted into the program at university is still way too low, in order to keep their wages and prestige up high.
-
IMO, there is absolutely a shortage of capable software engineers, in every Western geography that I hire in (Boston, Seattle, Zurich, Windsor, Barcelona, Amsterdam, and Prague). You might note that those are not particularly low cost locations. There is also a shortage of capable software engineers in India as well.
I see no outlook for that changing in my working career (call it 15 more years).
It's relatively difficult to excel in software engineering.
It's relatively easy to be good enough to get hired (and just good enough to not be fired).
If you know of strong local SWE talent in any of the geographies listed above, I'm probably interested in talking to them.
-
Imagine quitting Boeing over their scumbag ethics, and having to look for another job. There's not a lot of aerospace companies in the world. You would blow up your career and not change anything, they will just hire a replacement noob engineer for cheap and the world keeps turning, even after a few plane crashes and hundreds of deaths.
I've worked on products that can kill people, cause explosions or break limbs, electrocute. Very nerve wracking.
Walked out of an engineering job because I would not be given the time to do the safety testing. Anyone can be an "engineering manager" and instruct you to subvert safety, testing etc. in order to save time and get the product to market. Of course, you are somehow still the responsible person. Wife and kids, bills to pay - you'll do what's needed to keep your job.
Yes, exactly, that, sadly, is how it is. Unless you're single and/or have a pile of cash in the bank it ain't easy to take the risk.
-
IMO, there is absolutely a shortage of capable software engineers
Well, you either hire 10 "capable" engineers or 17 noobs to be on time.
In the context of this topic we are not discussing about a development team of 20 engineers but about an international corporation and their global policies.
The goal is to hit the target and develop the system(satisfy requirements) with gven constraints (of budget and time). If Boeing develops life-critical software relying on the capable-ility of whole (100.000%) team, instead of applying a rigorous systemic approach that is intrinsically robust against bad days of anyone involved, then this is an approach that will fail every time.
I woud expect that at Boeing, even if one replaces whole development team 1:1 with total noobs (outsourcing), the only difference in outcome would be that the development takes longer. And not that the software met the deadline but is dangerous (as some suggest). Then, you hire 17 noobs instead of 10 "capable", you are on time and noone has to die.
-
It's the supply and demand curve applied to labour. The more engineers the better for economic development. Governments and corporations want them by the zillions.
But the shortage of engineers is a myth, there's no shortage - it's that corporations want them cheap. They go to the cheapest labour developing nations, abuse the H-1B Visa (https://en.wikipedia.org/wiki/H-1B_visa) cry wolf and complain "can't find no S/W engineers", get grants, funding etc. to bring in the masses that can't really write code and have fake credentials. The more supply, the lower the market price.
Just ask a recent grad how it's going paying off their student loan, if it was worth it getting a degree. Local talent is ignored and struggling to get a job.
Supply is carefully controlled for physicians and surgeons. How many are admitted into the program at university is still way too low, in order to keep their wages and prestige up high.
A former employer had a H1B engineer on my team, he was a nice guy, I liked him, nothing against him personally, but come time to renew his visa they actually had a fake job listing posted to show they were trying to hire an American citizen despite the fact that it was his job they had posted and applications just went into the bin. I was told it was common practice and apparently not illegal but I certainly do not consider that ethical.
-
IMO, there is absolutely a shortage of capable software engineers, in every Western geography that I hire in (Boston, Seattle, Zurich, Windsor, Barcelona, Amsterdam, and Prague)...
Many employers are out to lunch - asking for embedded, PC, Linux, cellphone apps, database and scripting languages for one programming position. As if people know and can do it all, have years of experience on each of those.
It's lead to people not applying or lying and putting fake qualifications on their resumes. Or contractors claiming guru-like abilities.
If you look at how many new university S/W grads there are every year, verses the business growth in your city, my locale does not have a shortage at all. If anything it is a glut for programmers and IT. Universities don't track if graduates are working in their field or doing retail to make ends meet. Migrants from other cities, immigrants with master's degrees also displace the new grad's opportunities.
Ada, VxWorks etc. is rare and the reason corporations grow in-house specialty S/W teams.
Instead of farming it out to Clown co. in exchange for sales of some missiles.
-
IMO, there is absolutely a shortage of capable software engineers, in every Western geography that I hire in (Boston, Seattle, Zurich, Windsor, Barcelona, Amsterdam, and Prague)...
Many employers are out to lunch - asking for embedded, PC, Linux, cellphone apps, database and scripting languages for one programming position. As if people know and can do it all, have years of experience on each of those.
It's lead to people not applying or lying and putting fake qualifications on their resumes. Or contractors claiming guru-like abilities.
If you look at how many new university S/W grads there are every year, verses the business growth in your city, my locale does not have a shortage at all. If anything it is a glut for programmers and IT. Universities don't track if graduates are working in their field or doing retail to make ends meet. Migrants from other cities, immigrants with master's degrees also displace the new grad's opportunities.
Ada, VxWorks etc. is rare and the reason corporations grow in-house specialty S/W teams.
Instead of farming it out to Clown co. in exchange for sales of some missiles.
Sure, but it gets to that situation by employers getting new positions approved one or two at a time. So they have to roll everything into one. This nicely matches the tendency, particularly for our younger players, to make a list in the "Skills" section of their resume consisting of 20 or 30 keywords they may have run across in some class last year.
The manager is satisfied because he dosen't have to ask for too much. HR is satisfied because they get a candidate who fits their culture. The new hire is satisfied because of the 20 or 30 skills that were listed, only 2 or 3 ever are really needed during the first year anyway; the rest are quietly forgotten about.
-
IMO, there is absolutely a shortage of capable software engineers, in every Western geography that I hire in (Boston, Seattle, Zurich, Windsor, Barcelona, Amsterdam, and Prague). You might note that those are not particularly low cost locations. There is also a shortage of capable software engineers in India as well.
I see no outlook for that changing in my working career (call it 15 more years).
It's relatively difficult to excel in software engineering.
It's relatively easy to be good enough to get hired (and just good enough to not be fired).
If you know of strong local SWE talent in any of the geographies listed above, I'm probably interested in talking to them.
I agree. Few hardware engineers know how to program well. Having inexperienced or poorly trained hardware engineers write commercial code is asking for trouble.
My son is also an engineer with a double degree in engineering and computer science. He once asked the Computer Science lecturer why he had to learn "the same programming subject" in both disciplines. The reply was "They taught you how to program. We teach you how to program properly." It turned out nothing truer was said.
From my first hand experience, some years ago I saw horrific programming by three or four degree qualified low cost hardware engineers on one project who clearly did not really understand how a basic microprocessor worked, how ISR's were to be handled, how to write functions/methods, understand the scope or life of variable types, nothing about comms protocols, nothing about PID algorithms, and less than nothing about how to structure a program. They did not even know the difference between a CRC and a checksum, falsely documenting the use of CRCs when they were in fact checksums. A replacement engineer was hired to maintain/fix that code but he walked out of the company after 2 weeks saying he would rather be in prison. I then took it on to refactor/rewrite the code - 50,000 lines of C code (ie: Crap code), reducing it to about 30,000 lines and fixing about 100 major bugs along the way. Even Eclipse often could not handle refactoring function names, constants and variable names because they were such a tangled mess. It was soul destroying to have to do this for 18 months, and I was tempted to quit, but I saw it as a challenge with a goal at the end.
In contrast, at my previous employment, there was one well paid firmware engineer who was trained properly in his home country of Sri Lanka. He wrote beautiful code, well architected, easily maintainable and understandable. He was a thinker. He knew enough about SPI, i2C, UART hardware, and microcontrollers etc but occasionally he would ask me to explain some hardware design aspects. Great guy to work with. People like that are worth their money.
I suggest hardware engineers without firmware experience consider some professional training if it be relevant to their profession of future desires. I did a post grad course about 15 years ago which had a strong emphasis on good programming practices and it was worth the cost effort.
-
In Germany you can study EE with a specialization in computer engineering which includes topics like computer design, MCUs, assembler, various programming languages and software development (methods and proper coding). It's ideal for an embedded/firmware developer, just the right mix of both worlds. But there is another important aspect. From my experience it's quite beneficial to have engineers who can talk to different departments and customers while "translating" between them. A typical situation is when sales, including technical sales support / sales engineer, are trying to sell a complex technical product to a customer. In a lot of cases the technical sales support doesn't have a deep insight into the product, only the big picture and the technical buzz words.
-
I agree. Few hardware engineers know how to program well. Having inexperienced or poorly trained hardware engineers write commercial code is asking for trouble.
Yeah that's true. OTOH, pure software engineers that don't have enough experience in embedded programming tend to write more structured, better crafted code, but often overly bloated. They also may not have a good grasp of real-time issues.
Most EE programs these days include a significant part in embedded software, which gives many young electrical engineers the false idea that they are proficient at this, when often they haven't really learned the basics of programming.
Good embedded software engineers are very few, and hard to find.
-
Good embedded software engineers are very few, and hard to find.
I'm available :)
Anyone interested, feel free to contact me. :)
-
I'm available :)
Anyone interested, feel free to contact me. :)
How expensive are you? If this thread taught me anything it's that software quality relates linearly to the dollars an hour paid to the programmers.
-
I'm available :)
Anyone interested, feel free to contact me. :)
How expensive are you? If this thread taught me anything it's that software quality relates linearly with the dollars an hour paid to the programmers.
Don't put all your cards on the table. Now he's going to charge you a fortune. ;D
-
How expensive are you? If this thread taught me anything it's that software quality relates linearly with the dollars an hour paid to the programmers.
My last employer paid me well. I could do that again. :)
The sticking point is that so many are against remote developers.
If anyone is interested in looking at my public STM8 code, here is a good starting point:
https://github.com/unfrozen/stm8_libs/wiki
-
"Programmers" need no credentials such as a degree in computing science or engineering?
This is the problem that makes airplanes, self-driving cars etc. crash.
People who have never used semaphores or know what a critical section or atomic statement is. Being "self-taught" doesn't make you a professional or skilled to write safety-critical software.
It's interesting only engineers are held responsible, but CompSci's and the self-taught geniuses are not.
-
"Programmers" need no credentials such as a degree in computing science or engineering?
This is the problem that makes airplanes, self-driving cars etc. crash.
People who have never used semaphores or know what a critical section or atomic statement is. Being "self-taught" doesn't make you a professional or skilled to write safety-critical software.
It's interesting only engineers are held responsible, but CompSci's and the self-taught geniuses are not.
Conversely it'd be a mistake to think people with credentials will write safe software or there being any guarantee they acquired the knowledge to do so. Even the manual auditing we very much depend on is little to no guarantee the software will be bug free.
-
No guarantees anybody is competent. Outstanding programmers are rarely noticed or rewarded, their wage is similar to the clown coworker that constantly has code problems.
Software errors, bugs are expected in software development and if they are due to a mistake coding, in the requirements, slipped through testing, incompetency, stupidity, corruption etc. - hard to know who messed up. You can always cover your ass.
-
I've spent most of my career in software and my anecdotal observation is that there is surprisingly little correlation between education and output quality. I've worked with people who had CS degrees, people who had other engineering degrees, people who had degrees as random as medieval history and theology, people who had no degree. Some have been brilliant, some borderline incompetent, some have been everything in between. Generally those with CS degrees bring certain knowledge to the table that those without don't, they tend to be better at the theoretical side of things but even that doesn't guarantee they will write good real world code. The self taught guys tend to have more gaps in their knowledge but occasionally you find one that is really good at something.
-
"Programmers" need no credentials such as a degree in computing science or engineering?
This is the problem that makes airplanes, self-driving cars etc. crash.
I'm not sure about that. Do you really believe software issues leading to deadly accidents are mainly caused by programmers that don't have the credentials?
Anyway, I don't even think this can really happen. I don't quite know about other countries, but over here, people without an engineering degree in EE/embedded software can certainly NOT get a job in those industries, or this is extremely rare and statistically insignificant. Checking that all people working on such a project are qualified is even part of the regulatory requirements.
Does that prevent software from being buggy?
As has been often discussed and is a well known fact (although the exact figures are debatable), up to 80% or more of the software issues in a given project are actually not due to a bad implementation (all the more if there is a strict verification process, such as in the aerospace industry), but rather due to incomplete or bad specifications. The engineers that write code DO NOT write those specifications, and in most teams, they are also taught not to challenge the specs, shut up and just code according to them.
-
I've spent most of my career in software and my anecdotal observation is that there is surprisingly little correlation between education and output quality. I've worked with people who had CS degrees, people who had other engineering degrees, people who had degrees as random as medieval history and theology, people who had no degree. Some have been brilliant, some borderline incompetent, some have been everything in between.
Prior to the advent of bootcamps, I'd have said that the average self-trained (no CS degree) programmer was better than the average CS-degree programmer. (Because they probably had some kind of "draw" that pulled them into programming out of interest, and it's hard to excel at a field that you're not interested in.) Post-bootcamp era, there are a ton of terrible bootcamp graduates who have watered this side of the pool down significantly.
Of course, lots of CS grads have deep interest and passion in it. Many others just "want a good job". Many of the pre-bootcamp crossovers were people who crossed over because they got a degree in X, but turns out they really loved programming more so did that as a career.
Generally those with CS degrees bring certain knowledge to the table that those without don't, they tend to be better at the theoretical side of things but even that doesn't guarantee they will write good real world code. The self taught guys tend to have more gaps in their knowledge but occasionally you find one that is really good at something.
I always enjoy proposals from people with no CS theory in their background that more or less start like "First, we'll solve the halting problem; then, we'll be able to do XYZ very efficiently..."
-
That was a question because... what guarantees low quality, unsafe software?
To write great software you need education, passion, experience, familiarity with the system, time to write, good testing etc.
MCAS is such shitware that a clown clearly wrote and tested that code. It should go for an award and in the annals as Best Killer Software award.
I looked at what employers are asking for in flight control software and autonomous car software devs. It's always a BSc in various fields with assorted experience.
Boeing had some openings needing TS/SCI (Top Secret/Sensitive Compartmented Information) with polygraph clearance. I had to give that a good laugh. They should instead put the polygraph on their executives, ask a few ethics questions about developing commercial aircraft.
-
(..)but rather due to incomplete or bad specifications. The engineers that write code DO NOT write those specifications, and in most teams, they are also taught not to challenge the specs, shut up and just code according to them.
Your "they are taught not to challenge" is a bit of abuse here.
In the same sense we are not taught to peel potatoes in the canteen, swipe floors, attend head management meetings etc. It is just not our job, while your expression suggests software engineers are lazy and/or incompetent. You describe this attitude as something bad, not noticing that it is the essential part of the cooperative environment, that you do not have a colliding ranges of competences. Do you expect management to peel potatoes, software developers to manage requirements and requirements team to take care of the canteen menu?
What is wrong with the concept of teams responsible for requirements doing the requirements?
I am trying to imagine such vision of the development where lower layer challenges the higher layer. Not only this is not scaleable (inverse flow of commands) but also, creating requirements for software development requires an access to the information that software developers simply do not have access to. To challenge incomplete requirements, first you would have to have at least the information the requirements team has. If you do not have this information, doing "challenging" instead of doing your job, because you know better how this plane shoud fly, then you are burning shareholder's money and I expect your boss to explain that to you.
Such vision is a total mess.
I would not want to fly a plane where development relies on challenging requirements team by software developers.
-
The Waterfall model of software development is just a theory, completely unrealistic. It's for morons, low intelligence executives and shareholders.
When you are at the lower layer (coding) you always run into flow paths that are undefined in the (top layer) requirements doc.
It's a halt on coding for many weeks until the requirements get updated and changes approved. This process takes time away from the coding portion of the project, blows up the Gantt chart, puts projects into a state of crisis and panic. edit: It's like hitting reverse on a project.
Here's a challenge grenade from decent S/W developers: "hey boss we should use both AoA sensors, not just rely on one".
-
The Waterfall model of software development is just a theory, completely unrealistic. It's for morons, low intelligence executives and shareholders.
Waterfall implemented correctly includes going back and forth between development and specifications in my experience. I agree it's impossible to make it only a one-way path. All it should enforce really is that any required change in specifications should get asked, and reflected at the specification stage. All it enforces is a logical sequence of steps, but I have always added local loops in the processes I have set up so that it's not just a one-way street.
Now in very big, heavily structured teams, the back and forth may either not be possible at all, or may take ages as you mentioned. So software developers will tend to shut up and if they ever run into a question of undefined cases, they may just leave it as is, putting software into an unknown state if the cases ever arise.
The point is not whether it's their duty or not to challenge specifications, it's not because they would find it fun to do so: it's the fact that they will probably HAVE to, as discussed right below. Thus if they don't, they just need to leave some execution paths unhandled. Not pretty. And if those cases are NOT specified, they are likely not to be checked either during the testing phase. Now standards in aerospace, as I reckon, require that there be 100% test coverage. How a given team justifies this is largely up to their level of practice and company policies.
Some static and dynamic code analysis tools can spot unhandled execution paths, but no tool is perfect and not all teams use them properly. And they don't solve the process problem: handling the going back and forth between development and specifications. Also, in a lot of cases, incomplete specs don't necessarily yield obvious unhandled execution paths that could be spotted by an automated tool. Many cases can be much trickier than this, so that it would be almost impossible to figure out whether some cases are not handled in the code without *knowing* a lot about the whole context.
When you are at the lower layer (coding) you always run into flow paths that are undefined in the (top layer) requirements doc.
I completely agree with that. Anyone with a slight bit of experience knows that it happens all the time - it's not just anecdotical. You specify things, begin to implement the hardware and/or software (or have people in your team do it), and pretty much invariably you'll run into cases that have not been thought about. You'll then have to take them into account, get back quickly with update specs, and move on. If this takes too much time, the project is screwed up one way or another.
Thinking that anyone, or even a whole team of dozens, can come up with complete specifications on the first run is completely delusional. It just doesn't happen.
Thing is, as I said, it's mainly a question of process and company policies, and only anecdotically a question of software developers being decent or not.
-
The Waterfall model of software development is just a theory, completely unrealistic. It's for morons, low intelligence executives and shareholders.
When you are at the lower layer (coding) you always run into flow paths that are undefined in the (top layer) requirements doc.
It's a halt on coding for many weeks until the requirements get updated and changes approved. This process takes time away from the coding portion of the project, blows up the Gantt chart, puts projects into a state of crisis and panic. edit: It's like hitting reverse on a project.
Here's a challenge grenade from decent S/W developers: "hey boss we should use both AoA sensors, not just rely on one".
Waterfall has its place, although as with the various "isms" these methodologies rarely work well in absolutely pure form. There is no one size fits all software development methodology, and there is no magic bullet although the various methodologies and management fads are often sold as such. I witnessed the transition from a more traditional waterfall process to agile and other similar buzzwords and observed that in practice "agile" was just an excuse to fire the spec writers and the QA and start shooting from the hip and pumping out half baked, barely functional products. The mentality becomes "no problem if we break something, we'll just fix it next micro release" except the next release comes and goes, new features and new bugs are introduced while old bugs languish and overall quality drops. They talk about shipping the minimum viable product, however as the old saying goes, you only get one first impression and many times the first impression of a product is crap. Of course any agile proponent will tell you that's not real agile and that's often true but that doesn't really change the fact that it is what is often going on in the real world.
There is no substitute for careful planning, adequate documentation, competent developers and QA. All of the various management fads and process buzzwords pretty much boil down to focus on the stuff that matters and spend the time getting work done. I often equate them to fad diets which all boil down to eat fewer calories and get more exercise. Everyone always wants a magic solution that will make all of this easy but in the end the solution has always been the same in essence.
-
MCAS is such shitware that a clown clearly wrote and tested that code. It should go for an award and in the annals as Best Killer Software award.
I looked at what employers are asking for in flight control software and autonomous car software devs. It's always a BSc in various fields with assorted experience.
My suspicion is that the development is very heavily mired in rigid process, which while designed to prevent faults, can also prevent common sense. I once knew someone who worked at some sort of graphic arts place, this was in the era of CRT monitors and they all had to be calibrated to display the proper colors and then a tamper seal was placed over the color adjustments. Well there were some monitors that were so clearly out of tune that it was plainly visible just looking at them, blacks were gray or green, washed out, worn out tubes, etc, any idiot could have dialed them in better than that manually but hey they had the calibration seal that had not expired so they were good to go!
I've seen software development get in a similar sort of situation where the focus is so heavily on rigidly following the process that nobody stops to question whether the process really makes sense or is adequate.
-
Functional safety standards ensure software is of high quality by requiring you to document to death (pun not intended) the software - risk analysis, fault trees, requirements, code, test, integration, changes etc.
Another layer is the documentation of the S/W development process. It starts with the corporation's qualifications, the engineering team's, the quality system, the documentation repository, management org chart etc.
i.e. how a change request gets created and goes through the corporation, who approves what, who is responsible, who signs off on the document, how are they qualified. Another document is on how to change the change request.
I would say it easily adds 3x the amount of time to a project schedule. Departments bitch and bicker, all have to change their old ways.
For old corporations such as Boeing that really had no competitor like Airbus, they had a monopoly. Microsoft is the same, a monopoly where many OS releases were total dogs. People collected their paycheques and followed the project plan despite knowing it was going to flop. But everyone stayed in business, no one got killed.
Lazy Dinosaur Co. cannot be flexible, adapt and stay organized well enough to produce a safe new model aircraft in a reasonable amount of time. The 797 program was launched 15 years ago.
Instead of making things more efficient and fixing in-house bottlenecks, let's follow the greedy MBA playbook and swing the axe. Fire the knowledge workers, bust the unions, use cheap labour, circumvent regulatory and roll out something old that's new in record time. And keep our antiquated processes in place because they are easy to thwart when they slow you down.
-
Waterfall Model considered harmful:
https://en.wikipedia.org/wiki/Waterfall_model
The Waterfall Model tends to be used when a software project ultimately reports to someone who isn't a software engineer. Let's say in this situation it's a mechanical engineer. It makes sense for the design and manufacture of a sheet metal panel or a casting with machined operations. The concept of N^2 complexity of a software project is lost on them, leading to specification and priority changes that are never allowed to settle. They pay a lot of attention to the price of things, not the cost of lost work.
How often do you hear questions like this:
"When will feature A be done?"
"How much time will feature B take?"
"Can you add feature C in your spare time?"
How often do you hear questions like this:
"What additional testing will feature A need?"
"How well will feature B be done?"
"Can we test feature C before starting the next task?
-
The above mentioned set of requirements is just a formal list of properties the design should posses. Usually this is given in a form of a test scenarios. For example:
- load 600kg.
- speed 150km/h
- distance 100kkm ...
etc.
An engineer/designer is not responsible for preparing the set of these requirements.
That's the first error. When the requirements are made, there has to be an engineer involved. Not necessarily the same that will implement them, but she has to know how she would do that.
Otherwise (and this happened many times) the delivered requirements can be unrealistic, impossible, or too expensive to accomplish regardless of the capacity of the engineers implementing them. That mistake had hit many times and we're still learning.
If the requirement says the software should work from Monday to Saturday, I implement Monday to Saturday. It is NOT my problem what happens on Sundays and I am not spending any time on implementing or testing Sundays. I do not deliver what I was not assigned to. I expect my boss to align me if I attempt to introduce anarchy and starting my own competing "management department".
Of course I might ask myself "wht happened with Sundays". Most likely I got Monday to Saturday and someone else got Sundays to implement because Sundays require much different implementation. Or maybe no, we do not implement Sundays at all and if the plane flies on Sunday - oops, BSOD. Not my problem.
That's exactly the type of reasoning that got us here in the first place. You see, an engineer is not just something that heats up the chair. She is supposed to have some intellectual capacity as to be aware of the context in which the requirements are implemented and to alarm others if the requirements don't make sense or simply are dangerous. If management doesn't care, she should search for someone who does care, be it a government regulator, police or the nearest responsible adult.
What's worse, by this reasoning, the managers who treat engineering as a commodity are actually completely right. If the engineers do not offer any benefits or responsibility, what does it matter who implements the requirements? It can be some outsourced company, an AI or a bunch of squirrels, the only thing that matters is the price of the job being done.
Looks like we get what we deserve. We are not necessary by this reasoning.
I cannot imagine ethics in software development.
This concept is totally un-scaleable.
It is scalable as long as you can talk with people above you and people below. I mean, sit down and actually talk, not filling some stupid forms and waiting two weeks till they get tossed into the trash.
-
That's the first error. When the requirements are made, there has to be an engineer involved. Not necessarily the same that will implement them, but she has to know how she would do that.
Thanks. Keep in mind my remark was limited to the scope of this topic, which is "outsourcing".
So, the full sentence (tyre example) should have been:
"outsourcee"(designer of the tyre) is not responsible for the duties of "outsourcer"(product manager that prepares requirements based on market study). I suspect it would be beneficial for the company for both of them to be engineers that know their trade but maybe not (https://en.wikipedia.org/wiki/Firestone_and_Ford_tire_controversy#Problem_detection) - leave the decision to the company. If it is more profitable to hire a bunch of squirrels to make strategic decisions, I cannot object, let them make money the way they want.
Otherwise (and this happened many times) the delivered requirements can be unrealistic, impossible, or too expensive to accomplish regardless of the capacity of the engineers implementing them.
Wait a moment, the qualities that you describe here are limited to even a higher level of management structure. These are closer to a head managment. I really doubt an outsourced $9 software developer is involved in negotiations whether Boeing's requirements are expensive or not expensive, realistic or not. Software developer is neither responsible for creating the requirements, nor for any activities that preceed the creation of those requirements in the decision flow. If the decision maker signs a deal and the company looses money because the deadline is unrealistic then why would you want a developer to be responsible for the failure?
It is nice to descuss those subjects but I am afraid that discussing responsibility on all layers of corporate structure at once, in one topic, this will not come to any conclusion.
The responsibility of software developer, please.
You see, an engineer is not just something that heats up the chair.
My responsibilities are limited to the requirements provided. No requirements - no code.
She is supposed to have some intellectual capacity as to be aware of the context in which the requirements are implemented and to alarm others if the requirements don't make sense or simply are dangerous.
The requirements are clear. Monday to Saturday. What is unclear here?
Dangerous? How the software developer is supposed to know if this is dangerous?
If management doesn't care, she should search for someone who does care, be it a government regulator, police or the nearest responsible adult.
Do you own Boeing's shares? Because you talk like Boeing shareholder.
Your reasoning is flawed. In such world, when a management generates a random set of requirements, you expect that a development based on those random requirements create product that is safe and reliable and meets customer requirement.
Shouldn't dangerous (or incomplete) requirements result in a development of dangerous product?
What's worse, by this reasoning, the managers who treat engineering as a commodity are actually completely right. If the engineers do not offer any benefits or responsibility, what does it matter who implements the requirements? It can be some outsourced company, an AI or a bunch of squirrels, the only thing that matters is the price of the job being done.
Of course. Software developers do offer the responsibility but this responsibility is limited to the requirements provided and not the duties of management layer above or testing and validation layer that is below. The only thing that matters is the salary and I must assure you that neither engineers nor shareholders care about the value of the lives of others as much as their own lives.
I cannot imagine ethics in software development.
This concept is totally un-scaleable.
It is scalable as long as you can talk with people above you and people below. I mean, sit down and actually talk, not filling some stupid forms and waiting two weeks till they get tossed into the trash.
Did you ever work in a corporation (https://en.wikipedia.org/wiki/Boeing)that employs 150000+ people? Not including those outsourced.
First of all there is no technical possibility to understand all the knowlege that goes into the aviation industry because humans live only about 80 years and not 8000 years.
Second, whenever you try to do the job that belongs to someone else (lets say adding the requirements by a software developer) then next day your boss receives a complaint from process manager, you are instantly aligned by your boss and blamed for the delays in the project: you are not executing the duties you were assigned to. After that forget about competing with "those who are aligned" w.r.t. promotions or a chance of being assigned to projects that offer perspectives. This is a one-time action.
Third, there is a number of engineers, managers, consultants, contractors hired that are responsible for that job - you have no chance to profit on introducing anarchy in a corporationon.
-
keep in mind if engineers write specs they will usually be easy and not push the limit so progress will be stalled
that is a whole thing in itself that requires back and forth between envisioners, designers and implementers
i would call these different kinds of engineers or the same engineer on different development days
-
keep in mind if engineers write specs they will usually be easy and not push the limit so progress will be stalled
that is a whole thing in itself that requires back and forth between envisioners, designers and implementers
That is another subject but irrespective of considering a conservative design or cutting edge design - that still requires rigorous specification and testing. In the context of the subject of outsourced software I cannot see how a $9 software developer could have any influence on which variant of software he is actually implementing. It is (Boeing) outsourcer that decides, not the $9 outsourcee.
Also, whether it is a 1million LOC project or 100 thousand LOC - a software developer gets about same chunk of requirements to implement at a time. It is just the count of chunks that raises (exponentially).
-
Haven't followed the thread in a while, but just a thought here.
We haven't said (at least, I) that engineers in charge of the development should write the specs. That would even be a pretty bad idea in many cases.
We said that they should be allowed to challenge the specs if there is any reasonable reason to, and be able to do so in a timely manner so the project doesn't get stalled or the issues don't get lost in time and forgotten about. The key idea being that when you start implementing specs, there are many potential cases in which you get to see they are either inconsistent or incomplete, whereas that passed unnoticed before any actual work started.
Engineering is not a linear activity, this happens all the time and is not per se a sign that engineers are asses. So just saying, whatever development process you use, it should certainly take this into account instead of politely ignore it.
-
When you say a party "should write the specs", there are no laws or rules about that. As I keep saying, engineers have all of the responsibility and none of the authority, in their work. A manager or exec can easily do a phone call demanding something, including a safety defeat, to get the failed project out to market.
Where did Volkswagen, Bosch, Audi etc. put in the requirements doc the need to detect an EPA (dyno) test cycle? If (steering wheel not moving) pollute less. Who signed off on it? Some lowly developer kept his job and added a nefarious subroutine.
This is the same situation as Boeing's happenings. A last minute mega-project failure comes up, "hurry! use nefarious software to cover up the defective hardware" so we can sell sell sell.
I see requirements and spec docs get treated like the Waterfall model, nobody has time to go back and update them and get them signed off. Late in a project where the rush is on, they can be verbal changes. Management and executives, not developers, have full rights to go in and override anything in them, including safety dependencies. Mutiny is not an option.
-
Haven't followed the thread in a while, but just a thought here.
We haven't said (at least, I) that engineers in charge of the development should write the specs. That would even be a pretty bad idea in many cases.
Or impossible, considering how specialized the jobs are nowadays.
We said that they should be allowed to challenge the specs if there is any reasonable reason to, and be able to do so in a timely manner so the project doesn't get stalled or the issues don't get lost in time and forgotten about.
We can have a discussion about how the world looks like or how the world should look like. I am afraid that every forum member here has his/her own view of the latter. In this very topic there were already several revolutionanry concepts of "flying safer".
Translating your quote into volkswagenian, as I understand it: "A low level ECU software engineer assigned to defeat device team should be allowed to solve a clean diesel emissions problem in literally no time and at no cost, if he suspects a defeat device is something shabby"?
I can see some serious problems here. The "should be allowed" - first of all you want an engineer to have a choice (to be allowed) to implement defeat device (resign from a right to be allowed) or not to implement defeat device (to allow him to say "no"). In the second case VW will have to shift this engineer to sharpening pencils and assign defeat device to some other guy. Both scenarios end with defeat device shipped. I do not think sane engineer would enjoy sharpening pencils long term so this path has rather low probability.
-
Not sure if stuff like these are somewhat common and because of the MAX are just getting the global spotlight, or Boing really has their quality/safety screwed up:
https://www.businessinsider.de/boeing-737-ng-qantas-finds-crack-airlines-inspect-fleets-reports-2019-10?r=US&IR=T (https://www.businessinsider.de/boeing-737-ng-qantas-finds-crack-airlines-inspect-fleets-reports-2019-10?r=US&IR=T)