1. 10

  2. 5

    I don’t think this is a productive way to think about code. Good developers know under what business conditions to build well crafted solutions in what parts of the codebase. An unconditional pursuit of perfection is very unproductive. My rule of thumb is that hacky code infects downstream. So, I won’t mind duck-taping a quick solution at the leaves of the dependency graph, but I’ll refactor it as soon as other things start to depend on it. Hacky code will typically involve a lot of unhandled corner cases, so it also helps to drop a log line any time something unexpected is detected.

    1. 3

      Aside: whenever people have used “broken window theory” I always thought they meant “broken window fallacy”, which may explain some deep confusion on my part.