What are salesforce.com and Apex like as an application development platform?

Question

I have recently discovered that salesforce.com is much more than an online CRM after coming across a Morrison's Case Study in which they develop a works management application. I've been trying it out with a view to recreating our own Works Management system on the platform.

My background is in Microsoft and .Net, and the obvious 1st choice would be asp.net. However, there's only really myself with .net experience and my manager with a more legacy Synergy programming background, and I am self taught and am looking at evaluating other RAD options (eg Ironspeed).

the nature of the business is in the main 2-5 concurrent construction type contracts that run for 3-5 yrs each, each requiring 15-50 system users. Traditionally we have used our character based Works Mangement system for everything and tweaked it for each contract. The Salesforce licensing model on the face of it suits this sort of flexibilty, but I'm worried about the development flexibilty/learning curve and all the issues that surround lock-in. There doesn't seem to be much neutral sober analysis of the platform on the web that isn't salesforce's own material/blogs

Has anyone any experience of developing an application on salesforce as compared to the more 'traditional' .Net route?

Answer 1

Salesforce is a rather painful experience for developing anything but the most simple applications. Salesforce has a very specific idea of what one would want to develop, and if your application isn't well within those boundaries, steer clear!

The governor limits are really quite pitiful: 16 level recursion, 1 meg heap, no more than 200 objects returned from a query, no more than 20 queries in one invocation. 10 web callouts in one invocation, 1000 items in a single list, and they go on. The ultimate result is that any cleverness you come up with to get around one limit runs afoul of another one.

Once you reach certain size, all your time will be spent on coding around these limitations. The language, Apex, doesn't really support any meaningful inheritance. Even seemingly simple tasks end up taking days when one encounters new and apparently arbitrary limitations, for example, all objects in Apex inherit from SObject; however, it is not allowed to instantiate a collection of generic SObjects, making it all but impossible to build useful utility libraries. Complex (even rather simple) database joins are not possible.

The tooling and support for Salesforce are also extremely weak. They are untrustworthy and difficult to use for real development processes. Deployment is a nightmare, since the tools have enormous difficulty working out complex dependency issues, and numerous entities that one will create in the course of normal development simply CANNOT be deployed programatically. Other little features are delightful as well, such as the fact that the language is case insensitive, but the IDE is case sensitive. There are no refactoring tools to speak of, so you get all the pain of a statically typed language, with none of the purported benefits. And the save/compile time is high- I see times of over 2 minutes with frequency. And, of course, if you have multiple compile errors in one save (and you will, since you won't want to be recompiling every change, with those 2 minute waits...) you'll only get one error at a time!

On a related note, you seem to have noticed that the Salesforce documentation is rather self-congratulatory-- well, it's like that ALL the way down. There is no mention anywhere in even the most deep-dark technical references of the common errors, or even the limitations of a given api or feature. It's all "here's the great thing you can do" and no mention of, "but you would imagine it would also do ___, but you'd be wrong! Dead wrong!" The documentation truly feels like marketing material all the way down. I've been programming in this environment for 18+ months now, and still occasionally have a hard time finding basics, like API reference.

Salesforce is not a flexible environment. It is not a rapid-development environment (at least compared to any other web-programming framework out there). It is not a good environment to build anything other than toy applications like those they show in their tutorials. Just say no.

Answer 2

I know this questions is a little old, but it'd also be worth looking at this question Disadvantages of the Force.com platform

I've been developing on the platform for a while and I couldn't agree more with Ben. There is so much wrong with the "development platform" that is force.com that I don't really think it's even fair to call it a development platform.

We've struggled with tooling support, which is terrible, deployment support, which is terrible and even their tech support which is, you guessed it, terrible.

The main point I want to make tho is that salesforce started off as a CRM and then they decided to add the "cloud platform" to their offering. The cloud platform tho, is heavily geared towards extending their CRM product and if what you're wanting to do is extend the CRM, then the force.com environment will let you do that nicely.

What it won't let you do nicely is ditch their CRM and let you build your own completely custom application easily. You are still tied into their security and user model, you will still have their standard objects in your database and you will still have their standard pages in your production environment. There is no "File -> New Project" so to speak.

Also, someone else mentioned it's "java based". This doesn't mean you can run java code in there. It means they've stolen some bits of java and bastardized it to look like java but really isn't... which is really annoying because you can't just grab a set of java libraries and import it into their cloud... so if you want to do something like parsing JSON... you're gonna be writing that yourself.

Ovearall, I'd avoid the force.com platform like the plague.