Or maybe this should be subtitled: “So ya wanna be a Salesforce Developer…” — you decide.
Almost a year ago, I left my employer of 10 years to become a Salesforce consultant for a former colleague of mine. I was at a point in my career where I had simply gone as far as I could go at my current employer and was ready for a change and some new challenges. Its been a very good year, I’ve learned more than I thought possible and became a Certified Salesforce Developer in September of 2013. Here are some of the things I’ve learned along the way from the perspective of a developer used to doing everything “his way” and from the ground up:
The Bad: (let’s just get it out of the way shall we?)
Visualforce Templating Language: I’m spoiled. I’d been using Django for 90% of my projects for the past three years and what I really liked about it’s templating language was — it was limited. I know that sounds weird, but I don’t like my front end template engines trying to do too much for me. Sure its nice to be able to specify a few quick tags and have some out of the box ajax work, but when something goes wrong, tracking down what exactly becomes an issue of finding a needle in the proverbial haystack. An example for me is the use of some tags behave differently based upon what sort of container they are in. Sometimes I’ll use an <apex:inputField… and get the label to show up automatically, but if I stuff it in a different container, that label disappears. Now that I *KNOW* that, it’s easy to watch for, but I have significantly less hair on my head after having this happen to me quite unexpectedly. I’d much rather have a completely minimized layer between my server and view pages and leave the structure to me, and for the LOVE of GOD in HEAVEN — can I have my HTML id attributes back?? Please?? Pretty please with sugar on top?? I realize that Salesforce needs to do some black box level “stuff” with those id’s but there has GOT to be a better way…I feel so dirty coming up with unique ‘class’ names in order to use jQuery selectors…I want my IDs!!
The cloud really is “the cloud”: Don’t get me wrong “the cloud” is great and leaves much of the day to day maintenance worries in the past. However, if you lose your internet connection your pretty much stuck. There’s no way to have a local development environment going to even run tests against. You’re dead in the water. As someone who is extremely used to having a local server running to develop against, this drives me crazy!!
The security of Salesforce is pretty darn good (which isn’t really a con but…), so good in fact that if I’ve not signed on to a particular org from a given IP address before (and have since cleared cookies, etc) I have to get a code emailed or texted to me to login. I get it, and understand it — but its extremely frustrating when you have a client that wants you to share an account. If I don’t “own” that account — that security token gets emailed to someone else. It seems just a lot of hoop dancing to get work done remotely. I’ve since learned to login to each an every org that I may use the next day from a different location to save me this hassle.
Debugging: Quasi-related to being in the cloud, debugging your custom code is a pain. I’m used to using some sort of step-through debugging. Salesforce has something similar in the developer console but its just not up to par. I find myself using System.debug all over the place and using the dev console to retrieve the logs and filter by debug statements. It works, but I’d rather have some sort of real-time feedback, like being able to print to the console or a step-through debugger to get real time feedback.
Source Control: I’d really like to see some sort of source-control integration. Yes you have the files on the server and can refresh from the server etc, but I was *really* hoping that since Salesforce bought Heroku that we’d see some sort of git integration and deployment. Its just not there and I miss it dearly.
Deployment: Nowhere near as bad as building a WAR file, copying it to the server, etc — but the user interface to build your deployment changesets has to be about the worst user interface I’ve ever had the displeasure of using. Anything you can deploy is sorted into this huge list of check boxes. Page after page after page of check boxes. The kicker is — the checkboxes don’t remember their state from page to page. Meaning I have to look at page 1, select any items I want to deploy, click add to changeset. The page takes me back to the packaging interface again where I have to click back into the list again and go on the the next page, etc…My first time building a changeset, I made the very unfortunate mistake in assuming that the check boxes remembered their state. Some 50 or 60 clicks later I click “add to changeset” and lost the previous selections. *OUCH* — nowhere NEAR as easy as a good old ‘git push’ from a particular branch…(see previous gripe).
The “No Software Illusion”: Salesforce makes things easy — very easy. So easy in fact that there is quite a bit you can do before you hit the point where you need custom code. However, many places in fact need that custom code at some point, but before they get there, they’ve managed to work themselves into an architectural nightmare. The “clicks not code” mantra is a good one, but I feel it gives the illusion that you don’t need an architect involved in your project. For me “Data is KING” and you need to take care of that data, and organize it sensibly. There are some architectural decisions that can likely be made up front to make later customization simpler. Decisions that can really only be made by someone with experience architecting solutions. No Software may be true, but no “geek” — certainly not a good thing.
The Good: (phew, we made it!)
Easy to Get Started: It’s very easy to get started in Salesforce. You only need to sign up for a “developer org” to get access to the force.com platform. The syntax is very similar to Java (take that for what its worth, personally I prefer python syntax, but overall I try not to get hung up on syntax alone…), so it should be very familiar for you if you’ve already done some Java programming. If you need to learn the syntax as well, then it may be a bit more difficult to catch on, but its still not very difficult. The hardest part is learning the various ins and outs of the platform itself and where things like workflow and validation rules can affect your code or vice versa. You also have to learn to program around the limits inherent within a multi-tenant system — (that means numerous companies are using the same resources that you are, so you all have to play nicely). Salesforce enforces some limitations to ensure your application doesn’t hog resources from other paying customers. These items by far are the hardest thing about learning the force.com platform but luckily when you’re just starting out your not likely to encounter much of these issues as you’ll be keeping your tasks fairly simple. You’ll have plenty of time to learn these limits as your projects increase in complexity.
Built-in REST API: The platform comes ready made for REST services. All standard objects are available for consumption via a REST API. You can GET and POST to these resources and work with your data from external systems without having to write or architect the REST service on your own. It’s a HUGE time saver.
You can also expose your own custom REST services with a simple class and annotation. Having been working quite heavily with it lately I have to say I’ve found the force.com platform to be the easiest of any framework I’ve been exposed to when it comes to creating web services.
Unit Testing: SF forces you to write Unit Tests. As someone who admittedly lets unit testing fall to the back burner (sorry, truth hurts — I’m working on it), its relieving that Salesforce is essentially forcing me into the practice of writing unit tests. (I still don’t write the tests first as my mind doesn’t work that way — again, working on it). The platform requires at least 75% code coverage and 100% passing tests before you can deploy into a production environment and I think that is great for helping you future proof your app. Please NOTE — there are ways to beat the system and cheat to get coverage so its not fool proof — but its on your conscience ;) When I first started I remember how satisfying it was to see my unit tests approach the 100% mark, it became game-like for me in a way.
There are some limitations in testing, and things I’m still wrestling with like testing my webservice callouts, but the platform apparently provides some rudimentary mocking to help get around this, though I’ve yet to get these methods to work as expected. Some of the workarounds involve actually checking within your code whether or not the current code block is being called from a test. This feels dirty and something inside me dies a little when I’ve had to use it. All that being said, the mere fact that unit testing is such a central part of the platform is very refreshing.
The Community: Having learned a few languages from the open source world, I’ve had to participate in several communities to get support while learning. I’ve spent many hours in IRC channels like #python and #django and have gotten incredible support from those communities. (Python is actually one of the better communities, so I don’t mean to pick on them), but far too often newbies are met with condescending, RTFM-type attitudes and answering questions with questions like “Why would you ever do it like that?” to which the answer is generally “because I don’t know any better, I’m still learning.” The Salesforce community seems to understand that newbies don’t know what they don’t know and are always willing to help and are friendly about it.
The users of the platform, whether developers or point-and-click-admins, are a very enthusiastic and fanatical bunch resembling a near cult-like existence. I say this in a good way however as its created such a friendly, helpful and understanding community. I attended my first Dreamforce in November of 2013 along with approximately 130,000 other people from all over the world and it seemed that every last one of them was more excited about engaging in the community, making new connections and catching up with past connections than anything else — not only to socialize, but to see how others were using the platform and how they can help each other get more out of it.
In closing — its’ been a “learning year” for me. Many say getting an app up an running in Salesforce is the fastest option available and I think that’s very accurate based on the functionality you get out of the box, especially if your app is leveraging the standard objects that Salesforce gives you (Opportunities, Contact, Accounts, etc…). As eluded to earlier, there are caveats to having so many point and click options and its always a good idea to involve a “geek” as early in your process as possible, but to get a basic app up and going that does 80% of what you’ll need it to do, there’s nothing faster. (As with any platform, its that last 20% that is hard).
For me, it all comes down to using the right tool for the job. The Salesforce platform just happens to be one of those multi-use type of tools that can sometimes fit the proverbial square peg in its round hole with a little coaxing from those in the know. Its worth it to take a look and get started adding yet another tool to your belt, because you can never have too many tools!
:wq!