Skip to main content
A migration can’t leave a developer experience in a bad state before improving it. Alex and Greg explain this in a BazelCon talk:
As explained in that talk, we want to maximize the benefits of Bazel, while deferring costs and known risks. We have to keep making improvements. Don’t say “we’ll just leave a TODO here to come back and fix the performance regression”. That TODO will be there longer than you think, maybe forever. In the meantime dissatisfaction might cause escalation to decision makers who de-fund the migration work. This is related to the YouTube results for “changing a tire while driving”. Even though a big migration is underway, it’s critical to the business that it be non-disruptive.