The problem wouldn’t be your competitors cribbing your ideas, it would be more like letting anyone with a bone to pick audit you for minor compliance violations, customers relying on internal implementation details or judging you unfairly for legacy horrors, or devs getting self conscious about their sloppy 2am fix and prolonging an outage for rational public image/ego reasons
Are you saying people worked less than 40 hours a week or more than 40 hours a week in those organizations? I’m assuming over, but it’s unclear to me from the tone of your post.
Been there too, and for me it was under 40 hours. Sometimes you'd have to cut people off and say they needed to go home if they were trying to pull more. But the whole 'strategy' is that cleaning up mistakes takes way more time than getting it right the first time, so keeping people fresh and without distractions is the most important thing.
Longer contracts are riskier. The benefit of having cheaper RAM when prices spike is not strong enough to outweigh the downside of paying too much for RAM when prices drop or stay the same. If you’re paying a perpetual premium on the spot price to hedge, then your competitors will have pricing power over you and will slowly drive you out of the market. The payoff when the market turns in your favor just won’t be big enough and you might not survive as a business long enough to see it. There’s also counterparty risk, if you hit a big enough jackpot your upside is capped by what would make the supplier insolvent.
All your competitors are in the same boat, so consumers won’t have options. It’s much better to minimize the risk of blowing up by sticking as closely to spot at possible. That’s the whole idea of lean. Consumers and governments were mad about supply chains during the pandemic, but companies survived because they were lean.
In a sense this is the opposite risk profile of futures contracts in trading/portfolio management, even though they share some superficial similarities. Manufacturing businesses are fundamentally different from trading.
They certainly have contracts in place that cover goods already sold. They do a ton of preorders which is great since they get paid before they have to pay their suppliers. Just like airlines trade energy futures because they’ve sold the tickets long before they have to buy the jet fuel.
Add(x,y):
Assert( x >= 0 && y>= 0 )
z = x + y
Assert( z >= x && z >= y )
return z
There’s definitely smarter ways to do this, but in practice there is always some way to encode the properties you care about in ways that your assertions will be violated. If you can’t observe a violation, it’s not a violation https://en.wikipedia.org/wiki/Identity_of_indiscernibles
Best I can tell is that overflow is undefined behavior for signed ints in C/C++ so -O3 with gcc might remove a check that could only be true if UB occurred.
The compound predicate in my example above coupled with the fact that the compiler doesn’t reason about the precondition in the prior assert (y is non-negative) means this specific example wouldn’t be optimized away, but bluGill does have a point.
An example of an assert that might be optimized away:
int addFive(int x) {
int y = x + 5;
assert(y >= x);
return y;
}
Yes, you can not meaningfully assert anything after UB in C/C++. But you can let the compiler add the trap for overflow -fsanitize=signed-integer-overflow -sanitize-trap=all, or you could also write your assertion in a way where it does not rely on the result (e.g. ckd_add), or you use "volatile" to write in a way the compiler is not allowed to assume anything.
Apple has a history of adding sensors, security chips, etc. a few revisions before the feature they support launches. It’s a really good idea because it helps them sort out the supply chain, reliability, drivers, etc. without any customer impact. It decouples the risks of the hardware project from the risks of the software project.
If things go particularly well you get to launch the feature on multiple hardware revisions at once because the first deployment of the component worked great, which is a neat trick.
Yeah, my iPhone 11 Pro came with the ultra-wideband chip in late 2019, and before the AirTags were released in early 2021, I believe the only thing it was used was for ordering AirDrop targets by proximity. It was clearly intended for the AirTags from the beginning, but it took about 1.5 years before it actually mattered.
