The false debate on monkey-patching

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:


class Fixnum

  def minutes

    self * 60

  end

end

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#minutes method with a different intention

Since 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?

Recommendations

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.

Advertisements

2 comments

  1. Interesting post.If you haven’t seen it, have a look at Joel’s < HREF="http://www.joelonsoftware.com/articles/FiveWorlds.html" REL="nofollow">Five Worlds<> post about this exact subject.While I have some concerns about the deep coupling introduced when you build dependencies on global state (and Ruby’s core classes are definitely global state), I am wary of falling into a different false dichotomy.We should be extremely wary of assuming that just because something works in a small team with infrequent turnover and high communication, it automatically does not work in a large team with sustained turnover and low communication.Or at least, we should not assume that it is any worse than anything else used by large teams with sustained turnover and low communication.My experience is that large corporations have a lot of trouble putting together stable software. Corporations deal with large teams, low communication, and sustained turnover of personnel.Simply prohibiting certain techniques does not make any of these problems go away. You need the processes that you mentioned to manage these problems.But here’s a question: If you construct a process that works in a corporation, isn’t it possible that your process will allow you to manage the risk of modifying core classes where appropriate?For example, you might manage the problem of corporate development by raising the level of communication and by using highly productive tools to lower the size of the team and increase developer satisfaction, reducing turnover.I guess I am trying to say that the problem of corporate development is rarely as simple as choosing the right idioms to produce low-risk, stable code.Typically, low-risk, stable development comes from the way you staff and manage projects, not from your coding style guidelines.

  2. @reginald braithwaite: thanks for the link. Indeed, from different worlds follow different game rules. And it’s the message I wanted to convey with my post.Code from a small team is not worse (nor is it better) than code from a large team. Since they live in different contexts, they should meet different goals.Having a process which would manage the risk of modifying core classes would be indeed helpful.What I like about your perspective in your comment as well as in < HREF="http://weblog.raganwald.com/2007/11/what-if-powerful-languages-and-idioms.html" REL="nofollow">one of your previous posts<>, is that the focus should really be on software development as well as people (recruitment and project management), rather than on the factual size of the dev team, which should be seen as a side-effect (and not as an invariant).However, the corporate world has its own environment (with large teams of 9-to-5 employees, looking for a salary rather than fun/productivity) and I think outcries from the corporate folks like the one from Jeff Atwood regarding monkey-patching is revealing.

Got a comment?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: