In software development, a "monkey patch" is a piece of code that modifies the behavior of an object or class at runtime. The term "monkey patch" usually implies that the class or object being modified is part of an open source framework of some sort, and that the code doing the modification lives somewhere else entirely (generally inside of an application running on said framework). It also implies that you're using a dynamic language that makes such modifications at runtime easy. The term is most commonly used to describe Python developers monkey patching Zope (or nowadays possibly Django or TurboGears) and related libraries, or to describe Ruby developers monkey patching Rails and related libraries. The practice of monkey patching has caused something of theological schism between the Python and Ruby communities.

The etymology of the term "monkey patch" is somewhat interesting. Back in the day, this technique was known in the Python community as "guerrilla patching," because if you think of your third-party framework as The Man, then your intrepid developer is analogous to a revolutionary freedom fighter staging rapid, unconventional attacks designed to subvert parts of the existing system. Also, "guerrilla patch" sounds way cooler than the usually more accurate term "half-assed band-aid." Of course, the closest that the average software developer will ever come to actual guerrilla warfare is the unrelenting ownership of a Che t-shirt. Through either common stupidity or a collective wry sense of humor, the term "guerrilla patch" evolved into "gorilla patch." This eventually gave rise to the term "monkey patch," which is both fun to say and carries all of the appropriate connotations of "monkeying around."

The phrase "monkey patch" and its ancestors are now language-agnostic; you could safely use them in conversation with developers of any stripe and still make yourself understood. Specifically amongst the Ruby community, this process may also be known as "opening a class," which is a technically accurate but rather dry way to describe it. Some Rails developers are campaigning to refer to the process as "duck punching," which is a reference to the concept of "duck typing," a principle intrinsic to many dynamically typed languages like Ruby and Python. The basic idea is that if something looks like a duck, walks like a duck, and talks like a duck, then you should be able to interact with it as if it were a duck. You don't care if it's actually a goose (that's close enough to being a duck for your purposes), and you shouldn't need familiarity with the entire avian family tree in order to interact with this thing; you just treat it like a duck and everything's copacetic (until it's not). Thus, "duck punching" is the activity in which you engage when the duck isn't saying what you want it to say.

Most Pythonistas and a few Rubyists view monkey patching as an inherently Bad Thing. All too often, a monkey patch modifies a globally available, relatively general-purpose class in order to solve a very specific, localized problem. A monkey patch might simultaneously solve a problem in one part of an application and introduce another, often larger bug elsewhere. Because code that performs monkey patching can be located almost anywhere, it is ridiculously easy to inadvertently introduce a problem caused by conflicting monkey patches, and ridiculously hard to debug that problem once it occurs. Existing monkey patches have a well-known tendency to break and die horribly when upgrading to the next version of a framework, as the patch often depends on code that has changed. Many opponents of monkey patching also hold the implicit opinion that the original developers of the framework are smarter than you, a lowly code-slinging peon, and if you find yourself constantly resorting to monkey patching to solve your problems, then you're probably doing something wrong. (This kind of mild snobbery is not language-specific. Python developers only half-mockingly refer to creator Guido van Rossum as the "benevolent dictator for life." The Ruby community, although it encourages widespread developer participation, is simultaneously nurturing a thriving elitist subculture of geek heroes and rock stars.)

Most Rubyists and a few Pythonistas view monkey patching as an incredibly powerful and indispensable tool. For many developers who use Ruby on Rails, monkey patching is damn near a way of life due to implementation maturity issues. Although the Ruby programming language has been around for more than a decade, it is only in the last few years that it has seen widespread use outside of Japan, and Python still predates it by several years. Zope was founded in 1995 and open-sourced in 1998; in contrast, the first release of Ruby on Rails was in July 2004. Rails' architectural foundation and the ease of development it affords are certainly attractive. However, the framework's youth means that you will almost certainly stumble across minor bugs and oversights in functionality on a fairly regular basis. Monkey patching Rails in the interest of expediency became such a frequent practice that appeared in so many code samples, that many developers new to the scene (and when you're talking about something like Ruby on Rails, pretty much everyone is new) began to believe that this was the preferred method of solving problems. This perception was also furthered by the fact that Rails itself monkey patches some of the classes in Ruby core libraries.

In reality, as with every other problem in software development, you should use the best tool for the job. Sometimes the best tool is a monkey patch, but often it's not. Monkey patching should be considered a last resort after more palatable alternatives have been discarded. You must be confident that you truly understand what the code you're tempted to monkey patch is actually doing, and how that applies not only to your immediate problem, but also anywhere else it may be used. If you don't have the time or wherewithal to do so, then you are courting certain disaster. In order to minimize unintended side effects, consider the more traditional (but also more tedious) method of subclassing the class you want to patch. That way, other users of the parent class won't get unexpectedly fucked by your monkey patch. If you do have to monkey patch something in order to fix a legitimate bug or add truly useful functionality, then the right thing to do is to also create an honest-to-god non-monkey patch that modifies the original source code and submit it for inclusion in the next release of the framework, making it available to all.

A monkey patch should not be confused with The Monkey Patch, a breeder of simians whose website employs the tagline, "For the love of the Monkey."

StrawberryFrog points out "I believe you can do this in Javascript too. C# 3.0 introduces "extension methods" which allows you to seem to attach a new method to an existing object type, but not to change existing behaviour."

Sources:

• Bicking, Ian. "There's so much more than Rails." Ian Bicking: A Blog. December 22, 2005. http://blog.ianbicking.org/theres-so-much-more-than-rails.html. Accessed: June 30, 2007.
• Fowler, Chad. "The Virtues of Monkey Patching." ChadFowler.com. January 26, 2006. http://chadfowler.com/index.cgi/Computing/Programming/Ruby/TheVirtuesOfMonkeyPatching.rdoc,v. Accessed: June 30, 2007.
• Grosenbach, Geoffrey. "RailsConf 2007." Rails Podcast. May 28, 2007. http://podcast.rubyonrails.org/programs/1/episodes/railsconf-2007. Accessed: June 30, 2007.
• "HOWTO: Monkey Patch Without Annoying Others." Sporkmonger.com. July 8, 2006. http://sporkmonger.com/2006/7/9/howto-monkey-patch-without-annoying-others. Accessed: June 30, 2007.
• Michie, Matt. "Understanding Monkey Patching." The Hive Archive. May 24, 2007. http://hivearchive.com/2007/05/24/understanding-monkey-patching. Accessed: July 1, 2007.
• "MonkeyPatch." ZopeWiki. http://wiki.zope.org/zope2/MonkeyPatch. Accessed: July 1, 2007.
• The Monkey Patch. http://monkeypatch.net. Accessed: July 1, 2007.