I’ve been bothered for awhile that when you search for advantages for developing on the Force.com Platform one of the first Google results is a thread on a forum listing many perceived disadvantages from a development perspective. Even worse, because of the rapid development of the platform many of the disadvantages listed are no longer correct. In this post I will discuss both advantages and disadvantages relating to development on the Force.com platform.

Advantages

(1) Quick access to Salesforce’s existing 82,400 company user base ( which has money to spend ) through the AppExchange (only a $300 listing fee).

(2) Piggy back off Salesforce’s powerful existing functionality, including:

    - User management and authentication
    - Administrative interface
    - Reporting and analytics
    - Dynamic API
    - Toolkits and integrations for other languages and platforms

(3) PaaS offering allows you not to worry about server maintenance or architecture

(4) Governor limits and test code coverage enforce some degree of best practice

(5) Security, both because of code review and because of high degree of control on the platform (see #2)

(6) Java-like syntax speeds learning curve for new developers

(7) Native “Visualforce” elements allow quick and easy information output

(8) Active community. Lots of information out there and active participation from Salesforce staff

(9) Object metadata can be leveraged for powerful functionality

(10) Actively under development (Big things underway with VMForce).

Disadvantages

(1) APEX is not a fully featured language
-Lots of things you might wish were there aren’t
- You will have to port them yourself or make outbound webservice calls

(2) Hard to know if you will really make money
    - Hard to impossible to find revenue numbers for the AppExchange
    - Per-user licensing creates a pretty linear margin on license fees (as opposed to potentially exponential on a metered system like GAE or EC2).
    - Data based pricing makes it pricy for folks with lots of data

(3) Debugging can be extraordinarily slow:
    - No real debugger
    - Places where you don’t even have a debug log (not enabled, in a managed package, reached the limit, or weird errors that don’t leave an entry).
    - Unfixed bugs or quirks on the platform that you wouldn’t expect (i.e. undocumented differences between commandLink and commandButton).

(4) Ideaexchange and other reporting tools tend to be admin focused
and geared towards new features, not fixes or better developer tools

(5) Governor limits sometimes make sense, but at other times they can be very difficult and prevent what would be best practice. Very easy to get in a place where you are trapped by a governor limit and very hard to know ahead of time whether or not any given practice you will take there (unless you already have a lot of time playing “dodge the governor limit” ). These are doubly a problem when it comes to test coverage.

(6) Developer tools continue to be somewhat lacking (even though the Force.com IDE runs in Eclipse you can’t use many of the Java focused extensions and build time is slow).

Incorrect Criticisms

(1) WRONG: There is no namespacing or packaging.

RIGHT: Namespace and packaging exist but are controlled via metadata (and unfortunately do not allow different folders in the Force.com IDE default view).

(2) WRONG: Security model is restrictive

RIGHT: A restrictive security model can be a robust security model. There are layers of complexity and in this case complexity equals customizability and power.

(3) WRONG: Difficult to convert SObjects to JSONObjects

RIGHT: JSONObject implementation makes this fairly simple.

(4) WRONG: Governor limits are terrible

RIGHT: Governor limits makes sense given the Force.com architecture (although they can be limiting and frustrating at times)

(5) WRONG: Support is poor

RIGHT: It is not realistic to expect excellent free developer support and if you want developer-focused support you should be willing to pay for the Premier offering.

My Recommendations

Do:

There may be some pain, but you should be okay developing small to mid-size apps on the Force.com platform, and you will do even better if you learn some Tips and Tricks and/or minimize coding in APEX (i.e. convert everything to JSON and do your processing in Javascript). I’d also recommend against trying to do anything too creative or with going in with expectations that are too high.

Don’t:

Don’t try to develop an enterprise app of significant size or scope on the platform. Even if the OEM pricing looks attractive, there is a good chance you will end up sinking ever deeper in a quagmire of multiplying unexplained buggy behavior and insurmountable governor limits (note: this recommendation may change with VMForce).

Takeaway

Part of the necessity here is understanding where PaaS is today, and the reality is that while PaaS as a service beyond IaaS, while developing rapidly, is not yet a platform ready for development of large enterprise ready apps. It is fine for extensions of existing technology, but be wary if you try for much more than this. This does not reflect poorly on Salesforce.com as they have been pushing the envelope on what is possible with all the force available to them. There are at the moment very many useful and potentially profitable things that can be done with the platform and if you have the time and resources, I strongly suggest doing them (or at least getting your feet wet while waiting for things to develop further).

Special thanks to Wes Nolte and Alex Sutherland for suggestions and corrections, as well as attendees at the Philadephia Dev Meetup (@botoscloud, @cashion, @matschaffer).

About these ads