Skip to main content
Before calling a task “done”, think about “acceptance criteria”. What is the “definition of done”? Did you fix the root cause, or only one proximate cause? As an example, answering a technical question for one user helps that user today. They may ask the same question again later, along with a hundred of their colleagues. Answering their question doesn’t close the loop, instead you should figure out what documentation they would have naturally consulted, or what error message they were presented with. Go fix those things, then just send them a pointer to that fix. For Bazel this often means adding validation steps, constraining legal values for attributes, and fixing error messages, in addition to getting into a habit of always improving documentation. A migration task often requires a three-step process where you introduce a “new way”, migrate usages one-at-a-time, then delete the “old way”. You must apply extra effort to finish the third step! Leaving the old way doesn’t just incur technical debt. It also allows the problem to get worse. Like the ratchet suggestion, you can sometimes prevent new usages of the “old way” which helps to avoid a moving target as you work to burn down the usages. Often, there’s significant simplification possible only after the “old way” has been completely removed, and that simplification allows your DevInfra team to keep your overall “complexity budget” balanced, so it’s important to advocate for prioritizing the “close the loop” work here.