>If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later. I do. I care very deeply about remo

>If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later. I do. I care very deeply about removing it later. The problem is that encapsulation is often mistaken as a strong justification for existence, and code that is written tends to justify its existence just by existing. That's to say that once code is in production, it's scary to delete. It's much less scary to delete a couple of lines of inline code wrapped in a comment that says "this is a hacky solution," because code that isn't encapsulated probably probably isn't used elsewhere. Or if it is, it's copy-pasted. The scary thing about removing encapsulated / abstracted things, is that oftentimes, other things refer to them, unbeknownst to the original author or their intent. It's pretty common (especially on larger teams) - the first developer writes up a hacky solution, the second developer abstracts that hack into a module due to some sensibility (abstraction, aesthetics, organization, etc), so now the hack has legitimacy. A third (or often the first developer) sees that the hack is in a module, assumes that the person who put it in a module had more information than when the hack was written and that it's now a first class member of the system. And first class members of a system take thought and time to delete.