I've gone more extreme on the 80/20 ratio, instead thinking as innovation points. Fine to have a few risky things, but that should largely be driven by the busi

I've gone more extreme on the 80/20 ratio, instead thinking as innovation points. Fine to have a few risky things, but that should largely be driven by the business, not dev. Having 20% risky deps that you might need to track changelogs on and fix adds up as you keep adding code. We do some wild GPU and data stuff, and time spent on weird js/python/infra/etc lib issues from old risky deps is time not helping our core and our users. Nowadays, we try to remove deps, not add. Putting 20% on innovation in the codebase makes more sense when thought of as % time improving, not the mix of risky deps. Ex: We invested in switching to more modern CI as useful innovation in the codebase (serverless GPU CI w gh integration, PR artifacts/snapshots/reproducibility, config as code, etc)... but done intentionally with boring code (gha/docker/packer). This brought in new ideas that took some iterations, but the boring code means it's only had one real incident, and all that has been justified in the business by the productivity ROI.