Speaking as someone who just sold a house in the Bay Area (Dec!), house prices here are very much "buying the payment".
The valuation of the property goes up and down directly with the interest rate.
The ROI of the house (we bought in 2016) was ~8% on the down payment over the past 10 years, excluding maintenance and interest charges. As an investment, property is not a very good one.
To get that 8% on the down payment, I spent 4% on the remainder. It really doesn't net positive after the mortgage interest (with a 20% down payment). It's about "forced savings" and having control over your environment.
As an aside, since people are stuck in houses (mortgage rates and prop-13), there is a definite lack of starter homes. Everyone adds the second bathroom, meaning there aren't any single bathroom homes to be found. That increases the market floor.
This isn't really about software quality, it's about the entire organization.
Consistency enables velocity. If there is consistency, devs can start to make assumptions. "Auth is here, database is there, this is how we handle ABC". Possible problems show up in reviews by being different to expectation. "Hey, where's XYZ?", "Why are you querying the database in the constructor?"
Onboarding between teams becomes a lot easier, ramp up time is smaller.
Without consistency, you end up with lots of small pockets of behavior that cause downstream problems for the org as a whole.
Every team needs extra staff to handle load peaks, resulting in a lot of idle devs.
Senior devs can't properly guess where the problematic parts of fixes or features would be. They don't need to know the details, just where things will be _difficult_.
Every feature requires coordination between the teams, with queuing and prioritizing until local staff become available.
Finally, consistency allows classes of bugs to be fixed once. Fix it once and migrate everyone to the new style.
There is a lot of fraud with UPI, specifically social engineering to obtain UPI OTP codes.
Since the card and the account haven't been previously associated, that's probably a risk model saying a human needs to verify the account before activation.
Indian cards also (I believe) have a mandatory 24 notice period prior to money being pulled - giving fraudsters a 24 hour starting gun to spend like crazy. That makes merchants that provide variable cost service on credit products twitchy.
The design of the system is very interesting, particularly how it expects to handle errors.
In 90's Telco, you used to have a pair of systems and if they disagreed, they would decide which side was bad and disable it.
In modern cloud, you accept there are errors. There's another request in ~10+ms. You only look when the error rate becomes commercially important.
My understanding of spacecraft is that there would be 3 independent implementations and they would vote.
The plane has a matrix of sensors and systems, allowing faults to be bubbled up and bad elements disabled independently.
The ADIRU does compare values to detect failures (median of 3 sensors), but they could only detect errors that last >1s. The flight computer used the raw data - because the sensors aren't interchangeable (they won't have consistent readings in all flight modes)!
Very nifty.
One thing, they say "memorisation period", I don't think it's a memorisation period? From my reading of the algorithm, it should be more "last value retention period"? Or "sensor spurious fault reading delay"?
Section 2.1 A330/A340 flight control system design
"AOA computation logic"
"The algorithm did not effectively manage a specific situation where AOA 2 and AOA 3 on one side of the aircraft were temporarily incorrect and AOA 1 on the other side of the aircraft was correct, resulting in ADR 1 being rejected."
So, you've got a system where _two_ of the three sensors are bad, and you need to deal with it.
Those being analog sensors measuring analog, physical things, they will never exactly agree with each other; so there's a plausibility window. As long as the fault causes the sensors to remain within said window they will be considered as valid.
Four of them operating in a redundant set and the fifth performing non critical task, as descripted in [1].
The fifth is also programmed by a different contractor in a different programming language: #1-4 running the Primary Avionics Software System (PASS) programmed by IBM in HAL/S and #5 programmed by a different team of Rockwell International in assembly. [2]
Maybe if they started ranking the answers on a 1-10 range, allowing people to specify graduations of correctness/wrongness, then the crowd would work?
https://en.wikipedia.org/wiki/The_Wisdom_of_Crowds