Recently we saw the resurrection of a fashionable question: to monkey-patch or not to monkey-patch. In other words, is it a good thing to extend or modify the runtime code of dynamic languages? Jeff Atwood and Reginald Braithwaite expressed radically opposite views, (seemingly) casting the debate as a ring fight.
I say “seemingly” because that is what it looks like from the outset, but as Reginald Braithwaite eloquently put in his comments thread:
I consider the Raganwald and Coding Horror blogs to be Frenemies: we pretend to disagree on a great many things, but the debate serves to further our common objective of getting programmers excited about programming. –Reginald Braithwaite
To come back to the issue at hands, Lhorie wrote a short and accurate post describing an open-source/corporate culture clash between the two perspectives, and I think you can also address the debate with a simple practical dimension: the size of the enterprise.
The startup world
In a startup environment, creativity needs to be king. There is a need to be inventive and have the freedom to experiment with new ideas.
In such context, monkey-patching can be a powerful tool. You can modify your language, you can build shortcuts, you can modify behaviors from base classes, and even dare to hijack the syntax parser.
The corporate world
In a corporate environment, stability is king. There is a need for structure and rules. Predefined steps to reach the goals is a good risk-minimizing strategy. Thus processes are often needed to be sure product development goes on a controlled track.
In such context, monkey-patching is a recipe for problems. You don’t want to assume the risks of name clashes, or your developers to lose time wondering about some code that does not work as anywhere else.
No winners, rather 2 perspectives
Jeff Atwood and Reginald Braithwaite both have legitimate claims. Atwood is the corporate world’s advocate whereas raganwald is the startup world’s advocate. And it is precisely because they are living in such different worlds that their perspective differ so much, that they don’t have the same definitions for good and evil. Different assumptions lead to different conclusions.
Case in point: 5.minutes
In a previous post, I got some (offline and online) criticism regarding this very simple hack:
self * 60
which allowed me to express my intention at a higher level. Was this bad?
As you probably guessed, my answer is that it depends on the context. If you’re 2 people working on the code, the author of the helpful hack tells his peer and it’s for the better at the end.
However, what happens 2 years afterwards, when the enterprise has 15 developers? Potential problems include:
- You might end up with several ways to get the amount of seconds from a number of minutes (because the most recent developers in the enterprise might not be aware of this monkey-patch done 2 years before)
- A very useful plugin might cause a name clash by redefining the
Fixnum#minutesmethod with a different intention
5.minutes is a very simple monkey-patch, I would argue for keeping it even if it were in the corporate world, for the sake of usefulness and readability (as a side note, Rails has it).
However, with more complex monkey-patches, that is, patches with a higher probability of conflicting with other parts of the code base, the reasons mentioned above would have more significance and most often than not I would argue against monkey-patching in the corporate world.
The mid-size enterprise
So it seems the startup world is monkey-patching-friendly, whereas the corporate world is not. What do you do when you happen to be in between, with a mid-size enterprise of say, 15 developers?
That’s the gray zone where you need to make trade-offs between the 2 perspectives, deciding what’s best for the enterprise, on a case by case basis. In the process, you’ll define your own culture. Questions such as these become relevant: is it really necessary to monkey-patch? What’s the vision for the enterprise as for the number of developers in the future?
I believe there are recommendations which should be followed regardless of the size of the enterprise. A simple and wise advice is to avoid opening up very basic classes of the Ruby standard library. Other sound pieces of advice (as well as alternatives to monkey-patching) can be found in a recent article from InfoQ.
To monkey-patch or not to monkey-patch is a false debate. The size of the enterprise, as well as the necessity to monkey-patch are more relevant questions.