Is reducing governor limits a good thing?
Next weeks Spring 11 Preview Release webinar will highlight some of the planned governor limit reductions. I wanted to ask the question, Is reducing governor limits a good thing?
Let's get the short answer out of the way to start with. Yes, reducing governor limits is a good thing……but I think we need to look a little deeper at what this really means in order to truly recognize the benefits and potential of such a change. Here's two that came to mind:
1. Avoiding the Tragedy of the Commons
Ecologists, and Organizational Theorists have often used the term "Tragedy of the Commons" to describe a "dilemma arising from the situation in which multiple individuals, acting independently and rationally consulting their own self-interest, will ultimately deplete a shared limited resource even when it is clear that it is not in anyone's long-term interest for this to happen." In the world of cloud computing, we use the term "governor limits" to avoid the Tragedy of the Commons where the overall performance of the multi-tenant platform may be degraded by some rogue process.
The reduction of governor limits is a great sign that indicates that the Force.com platform continues to redefine itself in its inherent ability to govern itself. This self-governing approach is even more apparent when you look back at the trend of the past few releases with continued reduction of governor limits. (Remember to register for next weeks Spring 11 Preview Webinar for more information here!)
2. The reduction of governor limits also influences how we develop on the Platform.
Having spent the past dozen or so years designing and architecting systems, and the past few years working heavily with Apex and the Force.com platform, I became very familiar with using governor limits to enforce best practices. With the reduction of governor limits, does this mean sloppy programing? How quickly did we forgot about efficient memory management when Java was released and we no longer had to worry about pointers in C for example? Looking from a different perspective, however, I see opportunity.
Let's think about the phrase I used in the previous paragraph: "enforce best practices". We often think of design patterns as a way to promote best practices, and enforce how we access aspects of the system, data or the view for example. Over time, patterns have been developed and shared for working on Force.com. While these are great, they are, at times, Force.com specific. These patterns are important, but I think we can broaden the use of patterns. For example, we can increase our use of leveraging open, well known patterns such as those described in the Gang of Four patterns book.
The GoF patterns are well known industry patterns that many developers are already familiar with. In fact, you will find many Force.com developers are using GoF patterns in their applications already. Reducing the governor limits can only open the opportunities even more! The result is developers new to the platform can become more efficient quickly—they can leverage their existing knowledge just as they can with language such as Java and Ruby with VMforce and Heroku.
In summary, as Orison Swett Marden stated, "Opportunities? They are all around us. There is power lying latent everywhere waiting for the observant eye to discover it."