• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

The cost of good Programmers/Developers.

Wombat

Master Contributor
Joined
Nov 5, 2017
Messages
6,722
Likes
6,459
Location
Australia
The proof is in the pudding.
 

DonH56

Master Contributor
Technical Expert
Forum Donor
Joined
Mar 15, 2016
Messages
7,835
Likes
16,497
Location
Monument, CO
Unfortunately that is the way of a lot of companies these days... Part of the problem is cost and schedule pressure lead to a lack of time and effort to mentor new teams and senior engineers who could (should) help are let go. The bottom line is important but too often top execs do not understand the trades involved (e.g. short-term and long-term costs in talent, not just money) with getting rid of key people. Losing talent costs, too.

IME/IMO - Don
 
OP
Snarfie

Snarfie

Major Contributor
Forum Donor
Joined
Apr 30, 2018
Messages
1,169
Likes
926
Location
Netherlands
Unfortunately that is the way of a lot of companies these days... Part of the problem is cost and schedule pressure lead to a lack of time and effort to mentor new teams and senior engineers who could (should) help are let go. The bottom line is important but too often top execs do not understand the trades involved (e.g. short-term and long-term costs in talent, not just money) with getting rid of key people. Losing talent costs, too.

IME/IMO - Don
I'm working in the financial market data industrie lot's of development work is outsourced to india. Their are hudge problems to plan any changes in software projects due to lack in experience for instance to change from an old oracle version to a new version where tables are crucial. They have to figuer that out after 4 weeks or more to solve such simpel given. Let me make clear to state that india developers are not worse than others but the large amount of them brings the avarage skills considerbly down besides also a culture difference gap.
 
Last edited:

pwjazz

Addicted to Fun and Learning
Forum Donor
Joined
Sep 21, 2018
Messages
507
Likes
746
It's an unfortunate mindset that treats software as analogous to a manufacturing process wherein you can linearly scale output by increasing inputs (developers, workstations, etc.). In software, often less is more. Especially on something as critical as flight control systems I would think that you want the minimum amount of code possible to meet the requirements in order to reduce the chance of bugs, yet the one thing that you're sure to get more of with more developers is more code!
 

Soniclife

Major Contributor
Forum Donor
Joined
Apr 13, 2017
Messages
4,500
Likes
5,417
Location
UK
The article reads like an attempt by someone to partially shift the blame to the low paid offshore resources, and away from the people who's job it is to ensure quality. This sort of business approach is endemic, most often it's only going to damage the company that gets it wrong, not kill people, it's horrifying to see that approach used in safety critical industries.
There is nothing wrong with any of the basic cost cutting ideas used here, as long as management is up to the job of managing the risks.
 
OP
Snarfie

Snarfie

Major Contributor
Forum Donor
Joined
Apr 30, 2018
Messages
1,169
Likes
926
Location
Netherlands
The article reads like an attempt by someone to partially shift the blame to the low paid offshore resources, and away from the people who's job it is to ensure quality. This sort of business approach is endemic, most often it's only going to damage the company that gets it wrong, not kill people, it's horrifying to see that approach used in safety critical industries.
There is nothing wrong with any of the basic cost cutting ideas used here, as long as management is up to the job of managing the risks.
Good observation. Another problem is that senior developers don't want to become for instance a scrum manager (because lack of pay, more hours an added resposibility) so the compagny put in place people that don't have any experience background. So a software change that takes normaly 1 week is prognosed/offerd for 3 weeks this because the experienced developer knows that his manager does know zip of actual development time this is realy a high cost post an a big dilema for top managment. The possible solution is Agile managment so you force experienced developers to become a manager or they could leave. Problem in that is their go's your experience.
 
Last edited:

Soniclife

Major Contributor
Forum Donor
Joined
Apr 13, 2017
Messages
4,500
Likes
5,417
Location
UK
I'd be interested to know what came up in any consultation process whilst getting rid of the experienced people, the ones I've been involved in usually read as very accurate predictions for what problems will be stumbled into, in the post deep institutional memory phase of the company. Also how many experienced people were released or sidelined for the crime of knowing.
 

Cosmik

Major Contributor
Joined
Apr 24, 2016
Messages
3,075
Likes
2,180
Location
UK
My impression of this problem was that it wasn't a bug in the code, but an error in the overall logic of how it was supposed to work. A 'coder' or 'programmer' is not someone who understands the logic behind an automatic system on an aircraft. A 'coder' simply does the lowest level implementation of a system which has hopefully been designed to a high level of detail by the true experts.

One thing I am interested in is whether 'maker culture' is making its way into serious engineering.

I think we live at a time when people have the idea that the previous barriers of entry to the engineering profession were due to institutional bias, toxic masculinity, etc. The prevailing mood is that we need to get to where the make-up of any profession reflects 'society' otherwise it indicates unfairness; in Britain the government has forced all businesses to publish their 'gender pay gap' statistics in the hope they will be embarrassed. Big business is buying into this in a big way. It seems to me almost certain that this will cause some companies to change the way they do things against their better judgement, even serious engineering.

And we live in a time when politicians and business leaders are prepared to pay rapt attention to a 16-year old's views on the climate. And a time when everyone thinks that 'apps' are the future, and that 'AI' can do anything. A kid with a phone and a few bits can build a drone. Self-driving cars are being designed by hippies. Why should the next generation of aircraft not harness this can-do spirit?
 
Last edited:

Neddy

Addicted to Fun and Learning
Joined
Mar 22, 2019
Messages
754
Likes
1,019
Location
Wisconsin
I PM'd medium to large scale public sector (govt) apps development for nearly 20 years before retiring a few years back.
Some observations (and yes, I'm pretty opinionated about it): RANT warning!

- Outsourcing to non-native-english-speaking resources (in my case for US mid-west user communities!) CAN work well, but takes significant overhead to make sure requirements and expectations of results and UI's are well communicated & understood, and then monitored closely to prevent it going off the rails...so, daily code reviews, etc etc.

- I always took a 'just in time' development approach (what came to be called Agile)...it just works better, and keeps everyone on their toes:)

- In the 'early' days (mid-late 90s), for the most part, business and executive IT managers stayed out of the requirements and deliverables management 'game', which left a lot of UI and 'appropriateness' decisions up to the PMs.
For good PMs, this was wonderful; for lazy PMs, it was a guarantee of a 'failed' project.
Which then led, over the years, to 'middle & senior management' starting to meddle more and more with code decisions (esp wrt privacy: 'you mean we can track everything our employees are doing within our software?? Hmmmmm")

- So the trend I saw was (not unlike other business 'evolutions') the migration of decision control from those who where intimately involved with the details (and implementation choices & vagaries) to those who had other, 'bigger' considerations, not the least of which was career ambitions (which led to short term 'victory proclamations' vs. long term value to the enterprise, employees & customers).

- In short then, I kept seeing talented PMs being 'big-footed' by ambitious 'senior' managers who mostly wanted acclaim and immediate bonuses/promotions - at the cost of QA rigor (hello, Boeing?), innovation, quality/elegance, and code oversight/review/maintenance (implement full regression testing? Nope, not enough 'value add')

- Apps Dev PMing went from a joyful, creative, team building, innovative, rewarding, customer-happy-making endeavor, to one in which your every action was being second-guessed by (usually, but not always!) less talented, less experienced 'managers' up the food chain, and so became an exercise in agony instead:)

So now we have web-apps that are intentionally designed/intended to mis-lead, or mis-direct the users (ex: how banking/credit card apps hide some of the most pertinent consumer info away buried under layers of sub-menus)....and inhale ALL browser actions into data repositories for further mass marketing/deceptions/influences - or worse. ("CitiBank" here will ensure I see lots of ads from them shortly:)

Not at all surprised at this 'take' on Boeing's apps dev decisions - not so much about outsourcing as such, but the failure for those 'managers' to adequately fund the proper oversight and review of the incoming code (and requirements statements).
We had an oft quoted saying that sadly applies: "funding for serious risk mitigation only comes with huge death or dollar events" - usually after the fact.
:facepalm:
 

HammerSandwich

Major Contributor
Forum Donor
Joined
Nov 22, 2018
Messages
1,137
Likes
1,497
Why, those overseas coders must be the ones who decided to make redundancy optional & not to document the new behaviors. :rolleyes:
 

BostonJack

Active Member
Editor
Joined
Jul 2, 2019
Messages
288
Likes
350
Location
Boston area, Cambridge, MA
I'm currently developer adjacent (SQA and test automation engineer) so I *could* make a lot of observations, but I'll restrict myself to just one: software seems uniform to the uniformed, but different domains differ wildly in difficulty, development times, and consequence of shipping bugs. For example: real-time software controlling potentially dangerous physical processes; OS systems for multi-processor systems; verification systems for complex integrated circuits; and backend development for web-based systems that must scale dramatically all require quite different awarenesses, competencies, and development paces. Dispersing development teams globally doesn't make things any easier.

[first post! woohoo! I've been lurking for almost a year! thanks to you all for the informed community. love it.]
 

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,370
Likes
234,434
Location
Seattle Area
My impression of aerospace work in a company like Boeing is that it is highly spec driven. As such, it lends itself to outsourcing where the contract clearly stipulates the work to be done. And the work is all spelled out in the spec. So not surprised that they outsourced this way.

The cost to Boeing I am sure is far, far more than $9/hour. The go-between companies pocket a big chunk of money.

The problem with the scheme is that you don't get engineering feedback from whoever is writing the code. This can be good or bad. The contractors as a rule are told to do the job and stay quiet. They are in no position to being criticism of any sort, lest they risk losing the contract.

So ultimately, the blame is on people who designed the system but some extent on outsourcing work that doesn't benefit from experience of good software developers.
 

pwjazz

Addicted to Fun and Learning
Forum Donor
Joined
Sep 21, 2018
Messages
507
Likes
746
the blame is on people who designed

Designs can and should be tested. I don't know how this works on something as complex as an aircraft, but in the run-of-the-mill software development with which I'm experienced, there are two basic ways to test a design, both of which fundamentally involve gathering feedback from actual users and domain experts in a user acceptance test. 1) prior to building the software, create a simulation based on the design and let users interact with that simulation or 2) let users interact with the finished product.

Specification-driven waterfall development really only allows for simulation, because once the product is finished, if users don't accept it, your entire timeline is blown. Iterative development provides the luxury of creating finished product early in order to gather user feedback early. If that feedback reveals deficiencies in the design, you can correct mid-flight (see what I did there?) and still have time to finish the project.

Other than cost, simulations have one significant downside - sometimes they differ from the final product in non-trivial ways that limit the quality of user feedback.

Do aircraft projects involve building a flight-simulator prior to actually building the plane? If so, I wonder whether the simulator in this case sufficiently modeled the real thing and what kind of user testing was (or wasn't) performed in the simulated environment that could have caught this design defect.
 

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,370
Likes
234,434
Location
Seattle Area
Do aircraft projects involve building a flight-simulator prior to actually building the plane?
For sure. Every part is simulated using fluid dynamics. And the whole plane needs to have a simulator anyway for pilot training.
 
OP
Snarfie

Snarfie

Major Contributor
Forum Donor
Joined
Apr 30, 2018
Messages
1,169
Likes
926
Location
Netherlands
Do aircraft projects involve building a flight-simulator prior to actually building the plane? If so, I wonder whether the simulator in this case sufficiently modeled the real thing and what kind of user testing was (or wasn't) performed in the simulated environment that could have caught this design defect.

What i understood is that customers could
choose to have a additional training for their pilots regarding this stall issiue or ( because of cost cutting measurs) not. It was not critical to have such traning by boeing you always could read the fu..ng manual.
 
Last edited:

DonH56

Master Contributor
Technical Expert
Forum Donor
Joined
Mar 15, 2016
Messages
7,835
Likes
16,497
Location
Monument, CO
If your self-driving car heads over a cliff, do you blindly trust it, or take over and turn the wheel? My brother is a commercial pilot flying 727/737's and basically said any automation messes up sometime, just take over and don't let it do something stupid. He also commented upon training, as in do it and put in the hours; apparently not all airlines are as rigorous in training and checking out their pilots, and in the air is not the time to RTFM.
 

mansr

Major Contributor
Joined
Oct 5, 2018
Messages
4,685
Likes
10,700
Location
Hampshire
If your self-driving car heads over a cliff, do you blindly trust it, or take over and turn the wheel? My brother is a commercial pilot flying 727/737's and basically said any automation messes up sometime, just take over and don't let it do something stupid.
Have you read the preliminary report from the Ethiopian crash? Best I can tell, the pilots tried repeatedly to take over, but the thing would just kick back in and resume diving.
 

DonH56

Master Contributor
Technical Expert
Forum Donor
Joined
Mar 15, 2016
Messages
7,835
Likes
16,497
Location
Monument, CO
Have you read the preliminary report from the Ethiopian crash? Best I can tell, the pilots tried repeatedly to take over, but the thing would just kick back in and resume diving.

No, but my brother has, and flies them, and I trust him... Piloting is his job and not something I really know much about. Not really interested in a pissing match over it and don't claim any knowledge of my own. Not sure it is really germaine to the OP.
 

Cosmik

Major Contributor
Joined
Apr 24, 2016
Messages
3,075
Likes
2,180
Location
UK
No, but my brother has, and flies them, and I trust him... Piloting is his job and not something I really know much about. Not really interested in a pissing match over it and don't claim any knowledge of my own. Not sure it is really germaine to the OP.
So has your brother ever had this system kick in? And does he know the designers and software engineers and programmers, and does he trust them? Does he have a view on whether a single angle-of-attack sensor is sufficient and whether he would always be able to take over if the thing failed?
 
Top Bottom