views:

848

answers:

7

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?

+2  A: 

I haven't developed on the .Net side of Salesforce, I did create a few in house additions to a very large Salesforce installation.

What I can say about it is that the development tools within the system can be confusing and the largest bottleneck I always had (in development time) was to get the correct syntax for the queries I wanted. (caveat, this was back in 2007)

Ólafur Waage
The .Net comaprison was really aimed at canvassing opinion comparing it to SalesForce as a RAD development platform, rather than interfacing with SF via .Net which I know you can do.I was actually quite impressed with the dev tools: you get a lot of UI for free that can be developed in the browser with the option of going into Eclipse for deeper Apex stuff. Its just a question of how quickly you hit the 'edge' cases though
mhollers
+3  A: 

I can't really tell you how fast you'll hit the edge cases -- but I can tell you that it's unlike any other development I've ever done. The implementation time required to create a workable solution -- and the ability to rapidly iterate a solution for business sponsors to evaluate are unmatched by any environment I've experienced.

The Apex code is based on Java, with platform specific differences. However, some things can't be done through code. The combination of declarative (screen based) and code based implementation required to craft a complete application is hard to wrap your head around at first.

Due to the multi-tenant nature of the environment, there are 'governor limits' which prevent resources from being monopolized by a single organization. This restricts your implementation options in things like insert and update triggers.

Deploying your application is a very different experience as well.

Check out the developer training (Dev 501) available as video podcast on iTunes: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=325668840 You'll be able to see exactly what I'm talking about.

marfarma
+19  A: 

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 6+ 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.

Ben
I've worked with salesforce for quite a while now and I couldn't agree more with your post. It's gotten to the point where we're writing our own deployment tool and possibly looking into writing our own IDE extensions because what force.com provides just isn't even close to a compelling offering
lomaxx
I wish I could upvote this over and over. Salesforce's motto of "It's not software, it's Salesforce" is entirely misleading because it still takes a software developer and an inordinate amount of time to accomplish the most basic tasks. Throw in the recurring fees and the whole system starts to cost a lot more than it's worth.
Jake
+2  A: 

Listen to Ben. No really. Listen to Ben. Salesforce is an absolute world of pain. The only thing good about Salesforce is their marketing team.

+4  A: 

I know this questions is a little old, but it'd also be worth looking at this question http://stackoverflow.com/questions/1664503/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.

lomaxx
+1  A: 

It seems most of the answers on here are negative, and I'd say that it's always easier to blame a platform than it is to blame your own inexperience.

There was a learning curve for me and it was frustrating (coming from a Java background). The syntax was similar but the paradigm very different. After battling it out for a bit I've managed to build apps used by tens of thousands of users that scale perfectly, are easy to manage and secure, and that incorporate almost all traditional programming architectures currently embraced including the basics of OOP, MVC and many of the other 'Gang Of Four' design patterns.

If you'd like me to point you in the direction of example code, or grand applications built on the platform I'd be happy to help you out.

It's certainly the case that there are applications that work, and depending on the circumstances, Salesforce could be the right tool, but coming back after another 10 months developing on SF, I stand by everything I said above. The problems our shop encounters are never to do with scaling users, but with scaling data (which in our app is not a function of the number of users) and scaling features and complexity. I'd be curious to hear what the size of your apps is like on average. Glad to hear it's working out, though!
Ben
+1  A: 

See my answer in another stackoverflow thread: Disadvantages of Force.com:

http://stackoverflow.com/questions/1664503/disadvantages-of-the-force-com-platform/2702650#2702650

which I answered recently even though the thread was old because I just wanted to take the chance to sound off on how annoying the platform is. Those thoughts are very current.

I would suggest that if you do plan on doing anything with the platform, make sure some of your team members are Apex certified. In general, I would strongly recommend avoiding the platform entirely until they seriously address the developer experience side of things and where there are specific and very simple business cases.

My nickname for the platform is "Little Ease", named after a 4x4 torture chamber in London where you couldn't extend yourself in any one direction. You'll hit limits constantly.

Here's an older blog post, too:

http://suprablog.com/index.php/2010/02/25/salesforce-the-astonishingly-powerful-little-ease-platform/

dt