You already enumerated the reasons this happened, many of which were beyond your control. Just keep that in mind when you're writing the documentation you were

You already enumerated the reasons this happened, many of which were beyond your control. Just keep that in mind when you're writing the documentation you were considering. It will explain your thought process as a developer, and as a bonus it will help cover your ass when whiny engineers (and managers) begin to pick at your code choices. Heck, even just writing the documentation and having it in your back pocket will help you feel better, even if nobody ever sees it. Document everything over time, so you can show why you did "X" before you were told about "Y". Also document that you offered to do a rewrite but were rejected. Don't be afraid of naming names--not in a vindictive way, but very matter-of-factly. Engineers love to whine about other engineers' code, especially when they don't understand it, regardless of how well or poorly it was written. Ignore the haters. Ironically, it's the ones who complain the most who usually know the least. If your code works, there's probably little chance anyone will authorize any kind of incremental rewrite since a) it costs money (your time), and b) it will require testing (again, more money/time). Don't sweat it. Your code will join the huge, largely unseen iceberg of substandard code that underpins just about every project in the world. Welcome to the club!