A little while ago I posted about my first impressions of force.com. After playing with it for a while I decided to do something a bit more serious: to build a complete Salesforce/force.com app. The result – an embedded real-time group chat application for Salesforce CRM and Customer Services – can be viewed and trialled at www.chatloopnow.com but this post is about my experiences of building something ‘for real’ on Force.
The main thing I want to talk about is productivity. I previously wrote about how force.com makes it as easy to create new persistent object types as Smalltalk/Gemstone, and even easier than Ruby/RAILS. Now imagine that your Smalltalk or Ruby instance is hosted somewhere in the cloud, on a fully managed server that you didn’t have to configure or deploy to, and where the difference between being ‘in development’ and ‘deployed’ is a single click. Further imagine that your Smalltalk or Ruby instance comes with not just a web framework but with a complete set of functionality from workflow to email, from web-services to reporting. And by ‘comes with’ I don’t mean ‘has libraries that support’ I mean ‘has operational services with an API’.
My gut feel is that building web-based apps, with persistent data, a bit of workflow, a bit of reporting, etc., etc. is something like 4-5 times faster on force.com than the equivalent in Java/J2EE or .net. There are a number of contributing factors to this:
- The aforementioned benefits of developing on a hosted, managed infrastructure, or Platform-as-a-Service to give it its full marchitecture title.
- The simplicity of the application architecture. There are just too many ways to do things in Java or .net (and too many competing frameworks for each of the different layers of the web app stack). Force.com has a very specific and simple application architecture and component model; I neither particularly like nor dislike it but I understand it and it works.
- The pragmatism of the languages. Neither VisualForce (the web-page tag language) nor Apex (the component language) are going to win awards for elegance but they make up for this by ruthlessly making it easy to do the things that need to be easy. By which I mean things like: form submission, data layout, querying & searching persistent data, and accessing the various force.com services.
- Ease of packaging and deployment. Actually, having the difference between ‘in development’ and ‘deployed’ being a single click away is just a little too quick and easy for me given the vast distinction in semantics between these two states. Never mind, force.com has full support for the packaging and deployment of applications, including version and license management of the package. So no need for a build server (in fact, no need for a build at all, see later), simply package a release and install it into a test, staging or production environment. This is a matter of a few clicks with no scripting, installation or configuration.
- Support for, and enforcement of, testing. Apparently some members of the Salesforce/force.com ISV community are upset that Salesforce now insists on a minimum level of test coverage in order to deploy to any production environment. Are they mad? I wont go into the productivity gains I believe come from TDD itself but, if you have to do it, and you have to with Force, it has two crucial areas of support. First, any test data you create within the test method is automatically torn down at the end of the test. I’ll say that again: ANY TEST DATA YOU CREATE WITHIN THE TEST METHOD IS AUTOMATICALLY TORN DOWN AT THE END OF THE TEST. There are projects in the past ten years where that single feature alone would have saved us man-months of effort. Actually I won’t bother with the second (the ability to run parts of the test within the context of different users) as the first is good enough.
Of course, not everything is sweetness and light. Some of the development productivity is tempered by the quality of the development environment. The best environment for writing Apex is the eclipse-based IDE (which has a number of issues like intermittently working code-completion) where as the best environment for VisualForce is the browser based editor, so you constantly have to synchronise between the two. There is no support for refactoring and renaming or deleting anything is a right pain; something the IDE could make so much easier. As good as the support is for testing there are a number of nasty gotchas like test user accounts counting towards your license limit and the code coverage tool being pretty dumb about how it measures coverage … and I have to confess to being distracted by the coverage number and not concentrating on the actual effectiveness of my testing on occasion. And I’ve already mentioned the lack of debugging support in my previous post.
There’s also the matter of the Apex language itself. It’s strongly typed, but why? There’s no concept of a build and its entirely possible to have type incompatibility issues that only reveal themselves at runtime which seems to totally defeat the purpose of type safety. If any of the Force.com development team happen to stumble on this post, a small plea from me: keep all the querying short-cuts and the DML statements but lose the typing. The single best thing that could happen to Apex, in my opinion, would be for it to become more object-oriented and more dynamic. Dare I say it, a little more Smalltalk-like (or Ruby-like if that’s your particular poison).
But these are just niggles and quibbles; if force.com can be 4-5 times more productive with these issues, think of what it could be when they get ironed out. And if I sound a bit like a starry-eyed fan-boy then that’s because, to a certain degree, I am. I was trying to think of the last time I got so excited by a piece of technology. And then it came to me: force.com is the Apple iPhone of enterprise web-application development!