4 ms·

I think Hyrum’s Law should be best understood as a warning for users rather than as handcuffs for implementors: don’t rely on non-obvious implementation details

I think Hyrum’s Law should be best understood as a warning for users rather than as handcuffs for implementors: don’t rely on non-obvious implementation details. I’ve seen software break due to a race condition when an upgrade made something faster. Hyrum’s Law tells us the performance was a hidden part of the interface. Is the solution to never optimize anything? Instead, I claim the client code was broken all along.

fragmede 5y ago
Where client code is something someone outside the organization implemented and is using, that makes a certain amount of sense. But when the client is another internal team, and the SaaS product the company sells broke, the customer doesn't really care that the database team and the API team don't get along - the product is down and while it's down, no sales are happening. The point, thus, of looking into other teams is to get a sense for the challenges they face and to have a less adversarial working relationship with them.
- kibwen 5y ago
  In such a scenario I'd say that the distinction between the two teams is essentially imaginary. If management is forcing the downstream team to use the new API even if it's broken, and then management is forcing the upstream team not to break the API for the benefit of the downstream team, then the API is an illusion.