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

300px-Cows_on_Selsley_Common_-_geograph.org.uk_-_192472 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.

Interpreter_UML_class_diagram 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."

 

 

 

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS