Monkeypatching
Noun · Verb · Development
Definitions
Monkeypatching is the practice of dynamically modifying or extending existing code at runtime, typically by replacing methods, functions, or attributes of existing classes or modules without changing their source code. The term likely originated in the Python community but applies to any dynamic language that allows runtime modification of objects. In Python, you might replace a method on a class to change its behavior for testing or to fix a bug in a third-party library without waiting for an official patch. Ruby's open classes make monkeypatching particularly easy and common. In JavaScript, you can modify prototypes or override global functions. While monkeypatching is powerful and sometimes necessary (particularly for testing, where mocking frameworks use it extensively), it is generally considered a code smell in production code because it makes behavior unpredictable, creates hidden dependencies, can conflict with other patches, and makes debugging difficult since the actual behavior differs from what the source code shows. Safer alternatives include subclassing, composition, and dependency injection.
In plain English: Changing how existing code behaves while the program is running — useful but dangerous because it makes the code do something different from what the source says.
Etymology
- 1990s
- Dynamic languages like Python and Ruby allowed runtime modification of classes and modules. Developers began overriding methods and attributes on live objects to fix bugs or extend functionality.
- Early 2000s
- The practice was initially called 'guerrilla patching' (a patch applied aggressively at runtime). Through a homophone shift, 'guerrilla' became 'gorilla,' then softened to 'monkey.'
- 2005-2008
- Ruby on Rails popularized monkeypatching extensively, with gems routinely extending core classes. Python developers adopted the term and the practice, especially in testing.
- 2010s-Present
- Monkeypatching became both a pragmatic tool (especially for testing and mocking) and a cautionary tale about maintainability. Languages like Kotlin and Swift introduced controlled extension mechanisms as safer alternatives.
Origin Story
The Guerrilla Tactic for Patching Code You Don't Own
Monkeypatching is the practice of dynamically modifying or extending existing code at runtime, typically altering classes, modules, or functions in third-party libraries without changing their source code. The term has a colorful etymology. It likely evolved from 'guerrilla patching' (making stealthy, unofficial fixes), which was misheard as 'gorilla patching,' and eventually softened to 'monkey patching.' The practice became particularly associated with Ruby and Python, languages whose open class models and dynamic nature make runtime modification trivially easy. In Ruby, the technique was so common that Rails extensively monkeypatched core Ruby classes, adding methods like '3.days.ago' directly onto the Integer class. While this made for elegant APIs, it also caused conflicts when multiple libraries patched the same methods differently. Python's testing ecosystem embraced monkeypatching through the 'unittest.mock' module (and later pytest's monkeypatch fixture), using it to replace dependencies during testing. The JavaScript community uses similar techniques, though the term 'polyfill' describes the specific case of adding missing browser features. Monkeypatching remains controversial: it offers unmatched flexibility for testing, hotfixes, and extending closed-source code, but it can create fragile, hard-to-debug systems when overused.
Context: The term evolved from 'guerrilla patching' in dynamic language communities, particularly Ruby and Python, in the early 2000s.
Fun fact: Ruby 2.0 introduced 'refinements' specifically to address the dangers of monkeypatching, allowing developers to scope their patches to specific files rather than polluting global classes. The feature took years of debate before being accepted into the language.