It's a risky idiom in general because it's often used to prevent debate. "Every existing product has feature X, so feature X is table stakes." "Why are we testing whether we really need this feature, it's table stakes!" My observation has been that "table stakes" features are often the best ones to reject. (Not so in the case of this title, though)
I code a lot on these. They're amazing on planes and trains as advertised, but I also spend a lot more time coding outside because they don't have the glare issues of a laptop screen.
I generally agree with your original comment, and I think a lot about Schmidt's quote when operating in a startup context. You're right that it's ironic in the Google context. Search should absolutely go back to being measured on retention and they should disentangle from the revenue team. And I agree that the real death of Google was in the statistical game: 95% confidence in a microscopic metric improvement still lets through serious quality degradation 5% of the time. This gets to another important point: OKRs should be _big_ or they're not worth doing.
Start by answering why projects need to be easier to deliver. Of course they should be, but the nuance of the answer is the thing you measure. You see something that indicates that they're "too slow." What impact would you see on the R&D team if the delivery team did better? Go back to why you have a delivery team at all.
Or you can ask in the reverse: when would you stop wanting to invest in delivery beyond maintenance? What does "good enough" look like?
I think this is only hard for poorly informed KRs. If something has risen to your top hypothesis for what's holding your Objective back, just look at the signal that made you honestly believe this. Customers keep telling you the product is painful to use? You can rely on the same communication channel to discover when it's fun and guardrail that it hasn't also lost utility. If teams deliver their KRs but don't move the Objective then the problem isn't with the KR delivery.
> Unfortunately, due to a problem also present in the first public version of Bitcoin, Satoshi could never spend the money from that transaction.
What evidence suggests that this was unintentional? It offers a sense of fairness and objectivity from the originator, without generalizing the concept of a transactionless block or requiring any special logic to enforce it.
Do you have any sense of why? It works best for me on small teams and startups, since that's where we need people to own and iteratively address full problems. "Understand and address why users of type X aren't returning" is not too confusing, especially if you have good communication processes during the actual work.
I'm not the downvoter, but perhaps they were annoyed with "Would Google of" rather than "Would Google have." That particular error really gets on people's nerves.
We're going too deep into this, for alexgartrell's relatively simple claim that covariant return types have a reason for being in the language, and that smart pointers omit that capability.
But just to clarify: no base class implementation is aware of derived classes in the copying case, so your smell doesn't exist. See Scott Meyers' "virtual copy constructor" snippet half way down the page:
http://books.google.com/books?id=azvE8V0c-mYC&lpg=PT159&...
You can't do it that neatly without covariant return types. Ergo, you can't do that while returning safe, smart pointers.
There are cases where covariant return types are abused, so it's fine that you treat it as a code smell. However, C++ does make them necessary for several valid patterns. This does include alexgartrell's example, but here's a popular one:
I have a polymorphic type that should be copyable. Because of the limitations of C++ copy constructors and operators, my only option is to expose a virtual method (call it "copy"). The non-smelly semantics we want are such that if you call "copy" on an object, you get an identical copy of the same type. So if you call "copy" on a pointer of type A, you get an A. Call it on a B, you get a B.
The contract itself is polymorphic. It doesn't commit to returning any particular flavor of A.
We can implement this method if we return naked pointers. But if we want to be safe and return a smart pointer, we have to introduce dynamic casting or other worse smells.
Their polymorphic factory isn't returning "different types." They're both returning A. The derived one is just returning a specific type of A. If the shared "makeOne" returned naked pointer types A* and B* rather than shared_ptr, then this would all work correctly, thanks to C++'s covariant return type support.
Covariant return types are a powerful feature in a language that doesn't support other forms of return type polymorphism. shared_ptrs function so similarly to pointers that it can be surprising when they don't support this behavior. Surprise and capability mismatch with pointers are strikes against shared_ptr. But not sufficient ones to stop me from using them.