Facebook

73% of Salesforce developers want to stop being Salesforce developers? Say what?

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.

20 comments to 73% of Salesforce developers want to stop being Salesforce developers? Say what?

  • Hernan

    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.

    • Dan

      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).

  • Mark

    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

  • Learn SFDC

    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.

  • Michael

    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.

  • Karen

    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.

  • kevin

    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.

  • Colin

    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.

  • FStack

    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.

  • Someone

    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.

    • Dan

      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.

  • Hans Liss

    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.

  • Hans Liss

    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.

  • Cyberguy

    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.

  • Cyberguy

    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.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>