Disagree. There are lots of reasons TODOs live on, mostly having to do with stashing ideas that aren’t functionally critical, or pointers for future devs who might inherit the codebase without immediately grokking a performance optimization or corner case that occurred to the previous owner, but wasn’t important enough to deal with at that time. Sometimes, they just save face for the original dev who would love to make something better, but had to move.
Black-and-white rules like “No TODOs after review!!” are not only too trivial to enforce for a real production team working on deadline, they remove the soft fuzzy subjective edges that make what we do art, not math.
I vividly remember following yugop.com (Yugo Nakamura’s Mono*crafts) in college around ~2000, waiting for more experiments to be posted. To me that was what the web was for, far reaching and experimental design. This article was a reminder of how absent that kind of design experimentation is now, even as businesses and applications have gotten more experimental.
Black-and-white rules like “No TODOs after review!!” are not only too trivial to enforce for a real production team working on deadline, they remove the soft fuzzy subjective edges that make what we do art, not math.