Monkey patching: the good or bad?

Monkey patching involves dynamically modifying or extending the behavior of classes, modules, or functions at runtime.

Monkey patching

While it can be a powerful technique, it is generally not considered a good programming practice in most cases. Here's why, along with examples:

Maintainability and Readability

Monkey patching can make code harder to understand and maintain. When you modify the behavior of existing classes or functions, it becomes challenging to determine where the actual behavior is defined. This can lead to confusion for other developers working on the codebase.

Compatibility Issues

Monkey patching can lead to compatibility issues when code depends on the original behavior of classes or functions. If the library or framework being patched changes its implementation in a new version, your patched code may break.

Testing and Debugging

Monkey patching can introduce unexpected behavior, making testing and debugging more difficult. When a problem arises, it might not be immediately apparent that the issue is caused by a patched component.

Codebase Consistency

Consistency across projects and libraries is important. Monkey patching can lead to non-standard behavior that is not easy to understand for other developers who are not familiar with the patched code.


In collaborative projects, other developers may not be aware of or agree with the patches you've made. This can lead to conflicts and misunderstandings within the team.

Example of Monkey Patching:
class Dog: def bark(self): return "Woof!" def new_bark(self): return "Meow!" # Monkey patching the Dog class to make it "meow" instead of "woof" Dog.bark = new_bark dog = Dog() print(dog.bark()) # Output: "Meow!"

Instead of monkey patching, it's generally better to use other programming practices such as subclassing, composition, or extending functionality through proper inheritance. If you find that you need to modify the behavior of a library or framework, consider contributing to the project by suggesting improvements or submitting pull requests. In rare cases, such as fixing a critical bug in a third-party library, carefully applied monkey patching might be acceptable, but it should be well-documented and discussed with the team.

Pros and Cons

Like many tools in the programming toolbox, monkey patching can be employed for both constructive and detrimental purposes. While monkey patching can prove beneficial when applied with a clear understanding of its implications and as a quick interim measure to address issues when time constraints are tight, it is not advisable to treat it as a standard practice. Relying excessively on monkey patching can lead to a cascade of modifications that progressively obscure the actual behavior of code.

This approach is considered unfavorable because it introduces a dissonance between an object's defined characteristics and its actual functionality. The divergence between the source code's intended behavior and the observable outcomes can generate confusion during troubleshooting, particularly for individuals other than the person who implemented the monkey patches. In essence, monkey patching can be regarded as a form of unsociable programming behavior, disrupting code predictability and hindering collaborative development efforts. Therefore, while it has its uses, it's crucial to exercise caution and consider alternative solutions that adhere to robust software engineering principles.


Monkey patching, while sometimes useful for quick fixes or temporary solutions, is generally not considered a good programming practice. It can lead to code that behaves differently from its original design and cause confusion during troubleshooting, especially for others working on the codebase. Relying on more structured approaches and adhering to established programming principles is often preferred for maintaining code quality and collaboration.