Stack Overflow just posted their annual developer survey for 2015 – http://stackoverflow.com/research/developer-survey-2015. I was more than a bit surprised that Salesforce development topped the list of most dreaded technologies. Now I’m not questioning their results, but you know what Mark Twain is misquoted as having said – there are lies, damned lies, and statistics, and this one didn’t quite pass the smell test for me. I know a lot of Salesforce developers at all levels, and if 73% of them dreaded working on the platform I would expect to be having quite a few conversations consisting of people complaining about the platform and how they are studying other technologies in the hope to escape those dreaded limit errors.
In the survey, dreaded is defined as “% of devs who are developing with the language or tech but have not expressed interest in continuing to do so.” I know many developers who have come to Apex from other languages. I can’t think of any of them who are looking to do something else. There are some great things about developing on the Salesforce platform, and some very annoying things as well. I can see how someone coming to Apex from another language might find aspects of it very frustrating (don’t we all?) but I think most of us find the advantages far outweigh the disadvantages. Enough so that we are generally very interested in continuing to work on the platform as it evolves.
Something isn’t quite right.
So I asked myself, who were the respondents to the survey? It must have been a fairly small sample of Salesforce developers, after all Salesforce doesn’t even appear on the list of popular technologies (defined as most used), so less than 7.8% of the respondents would be Salesforce devs. Of course, this could still be a statistically significant number, but it does suggest that Stack Overflow does not necessarily attract large numbers of Salesforce developers.
And why would it? Any experienced Salesforce developer is much more likely to be active on the similarly named and often confused Stack Exchange – specifically Salesforce.StackExchange.com. If you look for answers on Salesforce or Apex questions, you’re much more likely to be directed there than Stack Overflow. Looking at Stack Overflow, the tag Apex has 667 questions. Apex on Stack Exchange has 7000 questions. Does this mean that Salesforce developers who are happier on the platform are more likely to be on Stack Exchange than Stack Overflow? Are the Salesforce devs on Stack Overflow more likely to be part time on Salesforce where those on Stack Exchange are full time on the platform? Are developers who spent their time on Stack Exchange less likely to have seen the ads for the survey (which are noted as appearing on Stack Overflow sites)? I have no idea. But I’d bet there’s a selection bias at play here, and I’d bet it’s significant.
So I call bullshit on this statistic. I think it falls into the category Stack Overflow uses to describe the results where “These results are not unbiased. Like the results of any survey, they are skewed by selection bias, language bias, and probably a few other biases.”
I think there is some extreme selection bias going on here. Nothing against Stack Overflow by the way – they are very transparent about the results and potential for bias. Unfortunately, I’m afraid a lot of people will look at that number and assume it means something, where in fact the hitherto unasked question – of how many Salesforce developers actually dread the technology they are working on, remains unanswered.
Note that StackOverflow is one of the sites in StackExchange. I’m not sure if the survey includes all the StackExchange language oriented sites, but it should.
Anyway, I think that the sample size for Salesforce developers in StackExchage/stackOverflow is low and the number may be biased by that.
I wouldn’t discard the result though. I think their is a complain for people having to use Salesforce coming from other environments, who are the ones most likely to use StackExchange.
Hernan: I’m aware that StackOverflow and StackExchange are related. It’s not clear if the survey went to StackExchange users – the survey methodology explicitly references StackOverflow only. I did not discard the result – on the contrary, I believe it accurately reflects the views of those who responded to the survey. I just think it’s likely selection bias. There is no doubt that Salesforce development is a significant paradigm shift for anyone coming from another language, and to a large degree Salesforce is weakest where other platforms are strongest (and vice versa).
I can understand (even with the biases – selection and others) why some people might dread it. It’s like: take away every tool that as a “modern” developer you’ve come to know and rely on; enter an environment where you have no control over other people adding things to the environment that make your code break; knowing YOU’LL be responsible when stuff breaks, even though it worked before the admin added stuff. What’s NOT to love? 🙂
Dan,
I agree with you that this study sounds biased. I actually took a course in college all about how easy and common it is for Statistics like this to be manipulated or just generally screwed up.
As a former .NET developer, who now works almost exclusively with the platform, I can say that I “get it” and sorry to hear that not everyone (as in Mark and Hernan) gets it too. Oh well, It’s their loss, I suppose.
Cheers,
Sara
Yes, most of the developers are not willing to take Salesforce Certifications. Because of:
1. ‘n’ number of Certifications
2. Certification cost is more
3. Need to pay Maintenance Fee every years twice or more, if we have more certificates.
4. No other company provides these many certifications, keep on maintaining them. Doesn’t look fair
5. Looks like Salesforce.com is getting more profit from Certifications.
Frankly, developers are not willing to take the Salesforce Certifications now-a-days.
Mark is spot on. You’re always (slowly) working with a moving target based on what other folk are adding. Dread is the correct word.
Michael, Mark: it works both ways. Admins have to deal with what developer’s add, since many won’t provide you details of what they’ve done, and developers have to deal with what admins add. Considering neither seem to talk to one another, this issue is inevitable. The key is communication between the two, but I know that’s not a common business behavior.
I think the data speaks for itself.
a) Most respondansts are under 30. Lack of experience of working (in a hosted environment). This type of development is not taught in schools.
b) Majority have 2-5 years or less experience. This denotes a lack of experience as well. Experienced developers are either not seeking advice or are going elsewhere
c) How many Salesforce developers seek answers on StackOverflow versus the Salesforce developer forums? I think majority of developers seek advice on SFDC Developer forums and other StackExchanges rather than Stack Overflow
d) The majority of respondents are self-taught or have learnt the technology on the job. I know some Salesforce developers who have no software development education or experience and only started developing after working in Salesforce. You need to learn computer science (community college or university) and its intricacies to be a good developer. There are no shortcuts.
I have been working on integrating our system with Salesforce and I can say its probably the worst experience in my career of 14 years.
I won’t deny some people have a bad experience. But would love to know specifics if you’d care to share.
I’m a Manager of Development. I have over 10 years of experience and have launched many successful projects. Two years ago, we ported our applications to Salesforce.
I want to run away. I am miserable. My developers are miserable.
Salesforce for developers is horrible, dreadful, and locks you into the platform forever.
People can have bad experiences on any platform. So as with the previous post, what are the specifics? Is the problem one of technology, or business, or process, or even the original decision to port the application (the latter comment a reflection of the fact that it is almost never a good idea to port or rewrite an existing application – see http://www.joelonsoftware.com/articles/fog0000000069.html )
Dear Dan,
You are asking for specifics – based on your experience with platform I am really surprised how you can not see it. Your experience speak for itself and I would not have overconfidence to challenge it so please bear with me here:
1) What is your debugging and troubleshooting experience with SDFC when you compare it with other development platforms? Having fun with System.Debug() style debugging like in 60s or 70s?
2) Have you tried to refactor medium sized solution on Salesforce? How funny it was? Great tools, platform helps, correct?
3) How about collaboration development with team of more then 10+ developers? How platform helps you to eliminate that people break each other so easily by introducing new dependencies, requiring profile configuration changes (obvious problem on every Salesforce project I have seen) or introducing new triggers which break what worked before, lack of versioning, rolling back etc. (“fixed” only recently by DX initiative – but even that is still not comparable to other options).
4) Development productivity is just horrible. So much clicking and navigating, opening 10, 15, 20 windows to troubleshoot and identify simple setting. One feel to click 100x before getting to the point where it can really start developing what one needs to do. Whole “codeless” idea of development may be great for simple sales and marketing automation; it is horrible idea for medium and bigger size projects.
5) How the platform helps you to profile you apps so you can proactively identify performance bottlenecks *compared* to other development runtime environments?
I apologize to sound too aggressive but when reading some comments here like “people who responded to Stack are too young” or “statistics can be manipulated” I have to question whether audience *here* actually has *real* development experience with full scale development platforms like C++, Java, .NET, Python, etc. toolchains and development environments as I doubt that anyone exposed to such experience can be serious to not see obvious limitations in supporting SDFC development (unless one targets only simplistic macro-like automation in SDFC for which such complex tools may not be really required – using Eclipse to automate mail processing or Case routing may sound like overkill if platform provides it OOTB).
My impression, when evaluating SDFC development environment compared to “traditional” development toolchains and runtimes is that SDFC, if used for simple sales automation tasks (hence “salesforce”) is more then capable tool. But when used for full scale development with complex integration involving 50+ developers it is really not tool for the job.
Totally disagree on so many levels.
1. You have to be an admin before getting into development. Salesforce is definitely not for those who like to keep their head down and code. So for such all-around capable developers sorting out permissions or noncode changes is not a problem at all.
2. Show me one more technology where total noob can build fully functional applications without even starting to code. All other technologies need head breaking learning curve.
3. Collaboration problems? Not sure how that is a problem when everything is in the cloud and Github integrates seamlessly with VS studio and Salesforce orgs.
Trust this is the future of software. Gone are the days where only the elite headbanging overly complex coders can build feature-rich apps.
What a caricature you’ve painted there. It actually isn’t that difficult to make great apps outside of Salesforce, and you don’t need l33t coding skills. There are lots of free resources to teach yourself, or you can buy a course/degree/bootcamp. Plus your support network (other devs) will be so much wider when you’re not limited to Apex.
Salesforce knows how to market the hell out of its “clicks before code”, showing folks the easy way to a dev job. And if you’re satisfied with that, more power to you. But hopefully you still take the time to learn core programming concepts so you don’t make a spaghetti mess of the org.
I have to agree with Petr here. Throwing all of your eggs in the Salesforce basket is a mistake. If you ever give other types of development a shot, you may find the possibilities more exciting, and the work more productive and rewarding. In comparison to most major frameworks and languages, Salesforce is underwhelming with no respect for professional developers as can be seen by their meager attempts to improve toolsets and address common complaints.
I have had my share of Oracle, SAP and other CRM systems but never ever have I encountered something as bad as salesforce, if you look at it from a technical perspective. CI is a nightmare, it’s inconsistent and sometimes even not reproduceable. Apex and API limits suck, enforcing dirty work arounds for what would have been clean code otherwise. Apex in particular seems inconsistent by design, like a poorly bred Java and .NET hybrid, minus the good parts. And I have never encountered such painful deployments before. Face it: There might be business value in salesforce but its integration technology seems like it has been written by an untalented junior developer, drunk, while being disturbed all the time.
We see the same things, but just see them differently. Some of the problems you address I attribute to it being very early in the life of the platform – in many ways it is years behind, in particular with regards to developer process. But I feel the strengths of the platform outweigh those weaknesses, and that they they are doing what is necessary to improve the platform in those areas (the upcoming Salesforce DX being a great example). I don’t see Apex and API limits as “sucking” as much as demanding developers write better and more efficient code – which I consider a good thing. Apex is different, but it has strengths that offset its weaknesses (in particular when dealing with the database). And as far as deployments being painful. Yep – you nailed it with that one.
My point is, the platform is challenging, and poses unique challenges in areas that are easy on other platforms. But it also provides enormous strengths and efficiencies in areas that are hard on other platforms. Whether it is bad or good depends on your own assessment of the balance between the two.
Dan you say “I don’t see Apex and API limits as “sucking” as much as demanding developers write better and more efficient code” but this is misleading.
The “efficient” code you speak of is merely code that works around Salesforce limitations. Bulkifying code is a clear example of efficiency, but what about being unable to make callouts once an email is sent or a DML statement is made? This is a limitation imposed by the design of Salesforce.
There is no software engineering methodology that I’m aware of that tells me a callout to an external system should not happen after you’ve attempted to update a database record.
Software developers often don’t think about the behavior of the underlying database system they are using, so it’s quite easy to build code that looks efficient, but really isn’t. In this particular case the logic is simple: once you make a DML statement in Salesforce you have started a transaction that does not end (and is not committed) until the end of the execution context. Callouts can take an extended amount of time, and holding that transaction open for that extended time can be very problematic in terms of creating lock situations that could severely impact the performance of the application – especially under load.
One could argue that Salesforce should offer the possibility to perform DML that is not part of a transaction, but that would lead to other issues (concurrency and race conditions) that are potentially very hard to detect and debug.
So I would argue that this particular limitation is not so much about efficiency, as it is about enforcing reliability at scale – something that developers often don’t think of until it is too late. Salesforce’s approach, while annoying, provides significant protection from what is really a very bad design pattern – making outbound calls during a database transaction. And it’s a really easy problem to work around – since all you need to do is make the callout, then chain to a another asynchronous operation to do the DML (or vice versa).
This response clearly indicates you have limited understanding of transactional database operations. There is no requirement that a DB transaction last for the duration of an execution thread. I can perform multiple DB transactions within a single execution thread context if I so desire. Something like Hibernate, as an example, gives me the freedom to define when I commit a transaction. I don’t need to hold the DB transaction open while I perform the callout.
It’s not bad design to want to make a call out after a DB transaction. And Salesforce enforcing this is not a good thing. It’s just another silly limitation of a CRM platform that people foolishly try to use for custom web development.
“So I would argue that this particular limitation is not so much about efficiency, as it is about enforcing reliability at scale”
This is the big difference I typically see between people who like Salesforce and people who don’t. People who are experienced programmers don’t need nor want Salesforce to hold their hand (and prevent their velocity). They would prefer the platform get out of the fking way and let them develop. I would bet my career on being able to scale a big deployment on JavaScript or Java on the backend vs any Salesforce developer trying to do the same. Suggesting that Salesforce is a platform that scales well is laughable for anyone that has spent serious time as a web developer.
Anyone who can’t see all the limitations of this platform generally haven’t worked with much else. I for one loath this platform, as it literally blocks my development velocity at every single step of the development lifecycle.
Salesforce is great for CRM and little pet projects that hang off CRM use cases. But for any kind of custom web development at scale, it is surely one of the worst options on the market, and they charge a premium for the privilege of using what is fundamentally a broken architecture.
I agree with you, Dan. Almost all of the things I’ve found frustrating with Salesforce over the years can be traced to three fundamental factors: Multitenancy, immaturity and the IdeaExchange model.
Multitenancy has caused design choices that may seem random, unless you understand the reasoning behind them. As you say, they do tend to force you to write efficient, well-designed code.
Immaturity issues are being handled by the steady introduction of new, much better tools and models into the system, like Lightning and Salesforce DX.
Finally, the IdeaExchange model, while frustrating if you can’t get enough people to vote for your favourite ideas, is actually a fairly sensible way to handle the challenges of choosing your priorities in a system this large, with so many very diverse users and use cases. It may not be perfect, but I can’t think of a better model.
I’ve always been impressed by how Salesforce seems to have such a sound basic architecture that they have managed to grow it from a fairly small size to the current behemoth, apparently without having to redesign the whole thing from the ground up along the way. And it’s very obvious that the system was built by experienced enterprise software engineers who wanted to impart some of their architectural standards on the customer side of the platform as well.
Oh, and please note that the same survey claims that 69.5% want to work with Haskell, and 75.6% want to work with C++, while 72% want to stop using Visual Basic. I don’t have anything against Haskell, but I wonder how many software developers even understand Haskell. And how many have actually used Visual Basic recently?
I think their way of determining those numbers (“We asked respondents what programming languages and technologies they’ve developed with over the past year and what languages and technologies they want to develop with. By comparing status quo vs. aspiration we can see how developers perceive available programming tools.”) probably didn’t yield the information they think it did.
I am a developer with 28 yrs experience in IT, last 5 years in SF. SF is a pretty cool way to build apps. Simple basic apps can be built very quickly.
However I do agree that when you hit one of their limits, you sometimes do say to yourself, ‘what where they thinking or smoking to do that’. Not all limits, just some.
With some of limits at times if feels like the development team released a version 1.0 of some feature set and then got bored and moved onto other things (like lightning, what crap!) rather than do a second release to put the polish on the 1st release so everyone that uses those features has a good experience.
The limits, where they make sense does make you think carefully about your design so that you produce an efficient capable design. If you write bad code/config is SF it comes to light much sooner as it is more likely to run foul of a limit as the data and functionality in your org expand.
Agree that source control and deployment are not mature.
Like all systems I have ever worked on, the initial systems rolled out give users new functionality that is based on the strengths of the underlying system & languages. Users are very happy with this at first but as time goes by the following things happen:
1) the new becomes the norm and expectations are reset to higher levels
2) they start to ask for new features which start to push the envelope of what the system can do easily and quickly, hence you have to customise or develop more to give users what they want and overtime these can take longer as the envelope is pushed further from what it does easily.
3) Market forces and the need to compete also drive new ideas that may push the systems capabilities.
4) Having to work with other systems and the way they do things can often mean that you are not free to build using SF standard functionality or practices but have to depart (and customise / code) in order to partly ‘fit in’ with the way the other system has implemented the business process concerned.
I like that at the end of the day you can build just about anything on SF if you are creative enough. People have built chess games on the platform and integration’s with minecraft as well.
https://www.absi.digital/en/Articles/Dev-Zone/gamification-visualforce-chess
and
https://developer.salesforce.com/blogs/developer-relations/2014/01/visualizing-salesforce-data-in-minecraft.html (more if you google it)
I agree that the statistics sound somewhat fishy given the sources. Although I can share the sentiment that development in Salesforce is not the same as development in other stacks, for various reasons. I wrote a blog post about it and it’s here. https://glcgrid.blogspot.com/2015/03/salesforce-for-developer.html
if you compare apex vs java, is like comparing a beetle vs a Lamborghini, if you are coming from java development this is a nightmare, that you might want to wake up ASAP, I wouldnt include the apex experience in my Resume not for a million of usd.
I have worked with Java as well and it is better language but not necessarily a faster development environment.
Salesforce lets a non-coder, that can think logically, build systems with quite a lot of functionality in them just by using the
configuration tools. Then if the business/customer concerned wants to further extend that functionality it may become necessary to code at that point. Whatever extra it is that they want to do is then likely to be doable via the programming language used.
The strength of Salesforce (and other similar tools to differing extents, ie MS Dynamics etc) is that so much can be done before the need to code arises by which time it is well established in a business.
ie it is good for systems that grow organically from small beginnings.
For systems that are large and complex from the start, spending the time to develop in Java, .net etc is the probably the better way to go.
Great comment Cyberguy.
We work with a technology called Pegasystems (Pega BPM) and your post reflects 100% the situation with that platform too.
That’s not always what I find. I love working with Salesforce but I do understand why some people might dread it. Especially with having to work with a moving target. Anyhow, great read as always.
Posted by James from purusconsultants.com
We are getting ready to jump into Salesforce, the technical platform has been chosen by the powers that be. With all the grumblings about technical challenges with Salesforce, there is another consideration I’m not hearing – if an organization ALREADY does not know how to do software development, Salesforce surely will not solve that problem, and comments from that organization will then fill this type of question when problems inevitably show up.
I can’t argue with that one 🙂
I don’t agree with the statistics. I am also a salesforce developer and very much happy with my profession. My friends are also working as developers and are satisfied with the work.
20 years in IT, software development in particular. Two weeks of being forced to work with Salesforce, and I am ready to quit and work at Walmart.
Salesforce tried to make their out of the box platform more flexible but it feels like walking through a bunch intersecting spiderwebs. Unless you document what’s in production and sandboxes well, it can be extremely frustrating to work with objects that already have triggers and classes.
I had a job integrating Salesforce with our booking system and it absolutely was the worst platform I had developed for.
Then we added Marketing Cloud into the mix just to get something worse.
Look, Dan, I am working as a Salesforce developer and I am totally happy with it, So, I do not agree with this your opinions in this article.
I also agree that the statistics are somewhat misleading. 73% seems unreasonably low. I cannot wrap my head around who in their right mind would actually like to be a salesforce developer. Sadly there is way too much false advertisement on the web …