4 ms·

One theory I’ve heard (I think from Yegge?) is that Google’s internal tooling is so good at dealing with breaking changes that they’re too cavalier about introd

One theory I’ve heard (I think from Yegge?) is that Google’s internal tooling is so good at dealing with breaking changes that they’re too cavalier about introducing them.

dastbe 5y ago
if you have the right company setup, headcount, and culture then you can absolutely build a world where teams can be allowed to force “perfection” over time, even with amazing levels of automation. i think the interesting thing is that while you’d think that is the ideal everyone should strive for, the reality is that’s inapplicable or detrimental to run most businesses that way.
- oblio 5y ago
  > build a world where teams can be allowed to force “perfection” over time, even with amazing levels of automation. I'm confused, did you mean "without" instead of "with"? Also: > i think the interesting thing is that while you’d think that is the ideal everyone should strive for, the reality is that’s inapplicable or detrimental to run most businesses that way. Why would you say that is?
  - dastbe 5y ago
    i meant with. google has built some really great tools for minimizing toil when pushing major changes across a codebase. even then, there’s a nontrivial overhead that is borne across the company. > Why would you say that is? many/most businesses don’t have the margins/scale/time to focus on it. in a lot of businesses (amazons included) the goal for the business is to try as many things as fast as possible and scale that which works and abandon what fails. the goal of infrastructure there is to get out of the way and enable the layers above to build things as naively and simply as possible with little to no churn.
  - emodendroket 5y ago
    I think we see a good reason here: normal people don't think "this API is so beautiful," they think "these clowns are making me do a migration yet again."
throwaway984393 5y ago
Even if that were the case, they clearly don't want to invest any extra time or money in refactor. So much of Kubernetes' design has been problematic, yet they just limp on monkey-patching and bolting on features that take years to go from idea to implementation. If you want any major changes or simplification in K8s, wait 3 years. A traditional FOSS project is not limited in this way. The developers often just start a new major version and overhaul everything. But they don't have to answer to "the business" or huge institutional users. Commercially driven open source will always be a product beholden to stakeholders, rather than technology designed to operate as well as it can.
- emodendroket 5y ago
  The last task I want to be doing is having to migrate my Kubernetes definition files to accommodate someone's bright new idea.
  - throwaway984393 5y ago
    You already have to do that every 9 months (or is it 12 now?) as there's no "support" after that. But the point behind major versions is you don't change your definition files as long as you stay on the old major version, which is supposed to be supported for a long time.
    - odonnellryan 5y ago
      More like 24 no? 12 until it is deprecated then 12 of support.
- oblio 5y ago
  > A traditional FOSS project is not limited in this way. The developers often just start a new major version and overhaul everything. And regular users hate this. Jamie Zawinski describes this funnily, eloquently and also offensively: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html > This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version. But he's right, and that's why: * regular application developers who don't care about ideology * and mass market users hate desktop Linux.

One theory I’ve heard (I think from Yegge?) is that Google’s internal tooling is so good at dealing with breaking changes that they’re too cavalier about introducing them.

dastbe 5y ago

if you have the right company setup, headcount, and culture then you can absolutely build a world where teams can be allowed to force “perfection” over time, even with amazing levels of automation. i think the interesting thing is that while you’d think that is the ideal everyone should strive for, the reality is that’s inapplicable or detrimental to run most businesses that way.

oblio 5y ago
> build a world where teams can be allowed to force “perfection” over time, even with amazing levels of automation. I'm confused, did you mean "without" instead of "with"? Also: > i think the interesting thing is that while you’d think that is the ideal everyone should strive for, the reality is that’s inapplicable or detrimental to run most businesses that way. Why would you say that is?
- dastbe 5y ago
  i meant with. google has built some really great tools for minimizing toil when pushing major changes across a codebase. even then, there’s a nontrivial overhead that is borne across the company. > Why would you say that is? many/most businesses don’t have the margins/scale/time to focus on it. in a lot of businesses (amazons included) the goal for the business is to try as many things as fast as possible and scale that which works and abandon what fails. the goal of infrastructure there is to get out of the way and enable the layers above to build things as naively and simply as possible with little to no churn.
- emodendroket 5y ago
  I think we see a good reason here: normal people don't think "this API is so beautiful," they think "these clowns are making me do a migration yet again."

throwaway984393 5y ago

Even if that were the case, they clearly don't want to invest any extra time or money in refactor. So much of Kubernetes' design has been problematic, yet they just limp on monkey-patching and bolting on features that take years to go from idea to implementation. If you want any major changes or simplification in K8s, wait 3 years. A traditional FOSS project is not limited in this way. The developers often just start a new major version and overhaul everything. But they don't have to answer to "the business" or huge institutional users. Commercially driven open source will always be a product beholden to stakeholders, rather than technology designed to operate as well as it can.

emodendroket 5y ago
The last task I want to be doing is having to migrate my Kubernetes definition files to accommodate someone's bright new idea.
- throwaway984393 5y ago
  You already have to do that every 9 months (or is it 12 now?) as there's no "support" after that. But the point behind major versions is you don't change your definition files as long as you stay on the old major version, which is supposed to be supported for a long time.
  - odonnellryan 5y ago
    More like 24 no? 12 until it is deprecated then 12 of support.
oblio 5y ago
> A traditional FOSS project is not limited in this way. The developers often just start a new major version and overhaul everything. And regular users hate this. Jamie Zawinski describes this funnily, eloquently and also offensively: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html > This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version. But he's right, and that's why: * regular application developers who don't care about ideology * and mass market users hate desktop Linux.