There is no such thing as "responsible monkeypatching". Even if it's fixing a bug in the source code or annotating, as the author suggests are practical uses.

There is no such thing as "responsible monkeypatching". Even if it's fixing a bug in the source code or annotating, as the author suggests are practical uses. Writing good code is about clarity and working within maintained expectations. People reading your code should be able to know what it does. If someone joins your team and knows that Method X in library Y is bugged, they will expect it to be bugged in your codebase as well, and reasonably so. The fact that you monkeypatched it is not something that they will be aware of, and can potentially cause bugs in their code as a consequence, costing them time and patience. A better approach is to use a wrapper instead of monkeypatching, or inherit from the bugged class and overwrite the bugged method. You get the same results, but anyone reading your code, with or without prior knowledge of how your code works, will: 1. Have immediate understanding that you've altered the source code in some way 2. Have a crumb trail leading them back to your custom implementation