The typical specifier does not understand the technical details and technical risks involved in building software. That's not their job. And if they did understand, engineers would become easily replaceable and their salaries would fall through the floor. For example, part of the job of marketing and sales people is to understand what the customers want, so they are able to provide great input when deciding what to build. It is not, however, part of their job to know how to build those things, which is why it's not uncommon for them to come up with ideas that are wildly expensive or literally impossible. And that's fine. Not every idea is feasible.
It's also often not specifiers' job to understand delivery risk, although it is highly desirable. Product people often don't have a good sense for whether building any given feature will be easy peasy lemon squeezy, or stressed depressed lemon zest. That's because there are knowns and unknowns that are deeply technical in nature, and only the people actually building the software have a hope of identifying where the landmines are. Product people with deep technical knowledge are incredible assets, but also exceedingly hard to find and probably outside of your price range.
So then who is actually responsible for the delivery of quality, working software? Whose job is it to deal with these deeply technical unknowns and the risks they pose? The most practical choice is engineering. Engineering is in the best position to understand and mitigate delivery risk — less so the individual engineers writing the code, and more so engineering management/leadership. Engineering management is the interface between the specifiers and the builders, and it is their job to ensure that delivery happens smoothly.
This is why I believe that non-technical engineering managers are generally a bad idea — but that's a topic for another time.
<https://www.tomdalling.com/blog/software-processes/against-must-haves-part-two/>
very respectfully,
kushal
ku on .NET
Mostly fun. Sometimes code. Maybe even dot NET
Whose fault is it anyway?
Could you say more about how these accidents were due to software issues stemming from outsourcing of development? Could you say more about how not outsourcing COULD have prevented the (2) accidents?
This is not what I understood to have happened.
The software developers writing the code 100% did not come up with or spec out how the MCAS should work. They're not aeronautical engineers, and they absolutely were not in the "system engineering" decision making change of the control system and how it should interface. They didn't decide to rely on one angle of attack sensor.
I know people like to shit on Boeing for outsourcing, but for FFS what do you think non-outsourced software developers were going to do? Fix the spec? Design it "right?" It WAS designed right to spec. The SPEC was bad.
"NO Billy, this is a bad control scheme. This is going to get people killed when the system forces action with 1oo1 voting on a key critical instrument. Especially when the methods and need to override such behavior is obfuscated from the pilot."
Non outsourced developers would have implemented it exactly as outsourced developers did because this is what they were TOLD to do. They didn't get to make ANY of those decisions. It would have still killed people.
Interestingly, my understanding is that Boeing maintains NONE of the production MCAS software was "outsourced" or written by "offshored" devs and was "effed up" in the good old US of A.
The software worked EXACTLY as intended. The system design was bad. The software developers did not do an iota of this system design.
<https://old.reddit.com/r/cscareerquestions/comments/1iuv5df/company_moving_to_only_prompting_no_coding/me2kt9m/>
very respectfully,
kushal
This is not what I understood to have happened.
The software developers writing the code 100% did not come up with or spec out how the MCAS should work. They're not aeronautical engineers, and they absolutely were not in the "system engineering" decision making change of the control system and how it should interface. They didn't decide to rely on one angle of attack sensor.
I know people like to shit on Boeing for outsourcing, but for FFS what do you think non-outsourced software developers were going to do? Fix the spec? Design it "right?" It WAS designed right to spec. The SPEC was bad.
"NO Billy, this is a bad control scheme. This is going to get people killed when the system forces action with 1oo1 voting on a key critical instrument. Especially when the methods and need to override such behavior is obfuscated from the pilot."
Non outsourced developers would have implemented it exactly as outsourced developers did because this is what they were TOLD to do. They didn't get to make ANY of those decisions. It would have still killed people.
Interestingly, my understanding is that Boeing maintains NONE of the production MCAS software was "outsourced" or written by "offshored" devs and was "effed up" in the good old US of A.
The software worked EXACTLY as intended. The system design was bad. The software developers did not do an iota of this system design.
<https://old.reddit.com/r/cscareerquestions/comments/1iuv5df/company_moving_to_only_prompting_no_coding/me2kt9m/>
very respectfully,
kushal
Meta LLM
Okay so I have a new idea maybe it's not just a new idea but anyway I have an idea a shower thought maybe so what I'm thinking is what if what if what if you ask the same prompt to multiple LLMs like or the same LLM multiple times and you take the responses all those responses and you feed it into the LLM again and you ask it to verify it or something like that right so maybe I can come up with something stupid like a prompt could be something like is it true is it true that more people more humans live in the temperate region of the Earth then they do on the tropical region of the Earth you know so that could be one question or another question could be something silly like is it true is it true is it true that more people live there are more people on earth than there are chicken on top of the peak of the Mount Everest right so that could be a silly question and maybe another question could be like hey review this review this piece of react component code that I have and tell me how I can fix it right so something like that you know like ask the same question to multiple alarms multiple times collect all the garbage together you know I mean collect all the responses together and then feed it back so yeah like just keep doing it until it becomes stable I guess I don't know well don't use it to train it I guess it's don't actually use the actual feedback to train it I guess but just just feed it you know just to see what what comes out just to see what comes out I guess what do you think
sincerely,
Common DB schema change mistakes | Postgres.AI
As usual, I'll be focusing on OLTP use cases (mobile and web apps), for which query execution that exceeds 1 second is normally considered too slow. Some cases discussed here are hard to notice in small databases with low activity. But I'm pretty confident that you'll encounter most of them when your database grows to ~10 TiB in size and its load reaches ~105–106 transactions per second (of course, some cases will be seen – unless deliberately prevented. – much, much earlier).
Subscribe to:
Posts (Atom)