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.
As an author, I have a deep interest in the way people learn technology, especially given the way technology has been impacting education in general. In fact, I created an entire Pluralsight course on the topic: “Learning Technology in the Information Age”, in which I discuss the advantages and disadvantages of different forms of content.
When I compare articles and blog posts with classes and books, one of the key differences is that classes and books provide curation. Curation is when the teacher or author selects the material that is important and then covers it in a logical order in which concepts build on each other to promote understanding. Articles, blog posts and videos on the Internet are fantastic when it comes to answering specific questions and providing information, but tend to be very poor on curation. This is why classes and books and courses still exist and thrive. When you want to really learn a topic, especially when entering a new subject area, good curation can dramatically reduce your learning time and help you achieve competence much more quickly.
Which brings us to Trailhead. I just finished looking over four new Trailhead modules, Data Security, Change Management, VisualForce Basics and Apex Testing. What fascinates me about them is that they provide something I haven’t really seen anywhere else. They aren’t articles. They aren’t books. They are, in a sense, almost pure curation of content. Think of them as a detailed course outline. They won’t teach you everything you need to know by a long shot, but they’ll get you started and leave you knowing what you need to learn.
I like the name Trailhead. When you go hiking you have a number of options. You can read an article about something along the trail, but that won’t prepare you for the hike – you won’t know about the dangerous spots or equipment you’ll need. You can hire a guide to take you on the hike and you’ll learn everything about the wildlife and geology and so on, and they’ll be sure you’re outfitted properly, but it will cost you quite a bit. Or you can get the trail guide, that will highlight the important things you need to know about the trail, the elevation gain, slippery spots and equipment you need, leaving you to discover and learn on your own as you take the path. Trailhead is your trail guide to Salesforce. It’s not THE ANSWER to Force.com training, but it’s a fantastic resource that serves a distinct purpose.
As I headed out from Dreamforce, one of my last stops was the developer library where I saw Andrew Fawcett signing his new book, “Force.com Enterprise Architecture”. It took me a while to get around to reading it, and I thought I’d share a few comments since he was kind enough to give me a copy.
As I discuss in my Pluralsight course “Learning Technology in the Information Age”, I feel that books provide a unique value proposition – along with taking a course, they are the best way to gain domain knowledge that is curated and organized in a way that is easy to learn. So that’s how I measure the value of a book beyond the obvious standards of clarity and accuracy – by choice of content and organization.
The first thing you should know is that this is not a book for beginners. This is not the book for an admin to read who wants to learn Apex. It’s also not the book to read if your goal is to obtain one of the innumerable certifications that Salesforce offers. This book is intended for intermediate to expert level Force.com developers.
The title, “Force.com Enterprise Architecture” is a rather generic title that is accurate enough, but as you will see, tends to obscure the real value of the book. This is a good book for any Force.com developer who wants to learn to how to architect solutions on the platform. The exact approaches in the book aren’t necessarily applicable or necessary for every solution, but they demonstrate the right way to think about architecture on the platform.
That said, if you are a developer who is thinking about creating a managed package or application to distribute on the AppExchange, this book isn’t just good – it’s indispensable. It is a “drop everything you are doing and buy a copy for every member of your team before you do anything else” kind of book.
There are many books on Salesforce and Force.com, including many books published by Salesforce itself, but what almost all of them have in common is that they are written by in-house developers and consultants. As far as I know there are just two books in existence written by developers who have shipped major managed packages on the AppExchange and this is one of them (mine is the other). Andrew Fawcett is CTO at FinancialForce, and he may know more than anyone in the world on what it takes to ship a Force.com application (myself included) – so if you’re even thinking about doing that, you’d be a fool not to buy this book and study it carefully. It’s full of the kinds of hints, tricks and suggestions that you won’t find anywhere else (including the books published by Salesforce – most of their authors haven’t shipped managed packages either).
And it’s a great complement for Advanced Apex Programming – you’ll find there is little overlap between them.
On each Force.com release, developers eagerly look through the release notes for exciting new features. I’ve found that the things that excite me most often aren’t the same things that thrill others. I often get most excited about small changes – sometimes they can have a huge impact on software design patterns.
This summer, the biggest feature for me is the elimination of Describe limits. This eliminates a huge Catch-22 when developing on the platform. On one hand, good Apex code is supposed to respect field level and object security. But the previous Describe statement limit made it difficult and sometimes impossible to do so on larger applications and systems, where the number of fields processed in an execution context could easily exceed the available limits.
The elimination of Describe limits does, however, raise an interesting question. How does this change impact design patterns and could other limits come into play? Or put another way – how costly are Describe calls in terms of CPU time?
Prior to now, the best design pattern for using Describe statements involved caching each Describe call so that you could at least ensure that you don’t call getDescribe on a field more than once in an execution context. The design pattern looked something like the getDescribeInfo function below, where the parameters are the field name and SObjectField token for the desired field:
Does it still make sense to use this kind of pattern? Or should you just call getDescribe() whenever you need describe information?
To find out, I did some benchmarking using the techniques described in chapter 3 of the second edition of Advanced Apex Programming.
I found that the approximate cost of a Describe statement is about 3 microseconds. This looked pretty fast to me. Can the earlier design pattern, with its cost of an additional function call and map lookup, be any faster?
The answer, as it turns out, is no. The overhead of caching and looking up data exceeded any benefits that might have come from avoiding the extra Describe calls.
Further testing showed the same results with SObject describes as field describes.
I don’t know if Describe calls on summer 14 are fast because work went in to optimize them, or because the platform is now caching describe data internally for you, but it doesn’t really matter. It seems clear that going forward, the optimal design pattern for describe statements is to use them inline as needed.
I’m pleased to announce my latest Pluralsight course “Data Visualization for Developers”. This is not a course on Force.com – but in some ways it’s even better. It teaches the principles and practice of data visualization using Force.com as an underlying technology.
The course is published on Pluralsight.com. Free trials are available if you are not already a subscriber.
I’m pleased to announce the immediate availability of the second edition of Advanced Apex Programming for Saleforce.com and Force.com
A few months ago, when SFDC announced the elimination of script limits, I knew that it had finally happened – a change that really impacted some of the content of the book. That led to some major changes in chapter three. And I figured, as long as I’m working on the book anyway; why not add a few more changes?
Chapter 6 extends the discussion on triggers to clarify some points based on questions I’ve received over the past year.
Chapter 7 has significant new content on batch apex and scheduled apex asynchronous patterns
Chapter 8 is a new chapter on concurrency issues (the later chapters have been renumbered).
Plus, there are numerous other smaller changes and additions scattered throughout the book.
All told, the book has grown by about 50 pages.
It also has a snazzy new cover – making it easy to determine going forward which edition you’re looking at.
Also, unlike last year, I’m pleased to announce that the Kindle and Nook editions are also available for those of you who prefer the eBook format.
The book available now on several Amazon.com country sites, and I’ll be linking the others as they go live. The links on the left will take you to the new edition – it will take a few weeks before all of the channel databases are updated.
I’ve been so busy for the past month that I haven’t had much time to post, but I’m pleased to say that I’ll be presenting three sessions at Dreamforce this year.
Monday at 11:15am, Moscone West -2009, High Reliability DML and Concurrency Design Patterns for Apex
It’s remarkable when you think about it, that even though Force.com is a highly scalable multi-user and multithreaded system, there is hardly any documentation on how to deal with Apex concurrency issues. I’m looking forward to shining some more light on this topic and sharing some of my own adventures (and misadventures).
Monday at 1:30pm, Hilton San Francisco Union Square – Community Success Zone Theater, Apex Design Patterns for Managed Packages
This one is for the ISV’s in the community, particularly the developers. Those of us who create managed packages are a growing minority – it’s nice to see us getting some more attention this year!
Tuesday at 5:15pm, Moscone West – 2024, Design Patterns for Asynchronous Apex
At first I was thinking – 5:15pm before the gala? Talk about bad timing. But then again, talking about timing (good and bad) is a large part of asynchronous apex, and if the late hour gives you a syncing feeling, so much the better 🙂
I hope to see many of you there. Also, be sure to attend the developer keynote on Wednesday 10:30 at Moscone South – Gateway.
And, I encourage you to visit this site sometime this weekend for another post that you may find of interest.
Perhaps the most surprising change for Winter ’14 is the elimination of script limits, to be replaced with a single CPU time limit for each transaction.
This is an extraordinary change, and it’s worth taking a few minutes to explore the consequence, both long term and short term, of this decision. Keep in mind, that what follows are my preliminary thoughts – I’m still somewhat in a state of shock 🙂
In the immediate future, I don’t expect this change to have any impact. I believe SFDC when they say they’ve analyzed the situation and that no current code will exceed the CPU time limits.
To understand the long term impacts, let’s consider the real meaning of this change.
First, managed packages will no longer have their own set of script limits, or their own CPU time – CPU time will be shared among all managed packages interacting with a transaction and code native to the organization.
Second, my understanding is that time spent within Salesforce code counts as CPU time. Up until now, script limits only impact your code – a long running built-in operation such as a sort or RegEx would only count as a single script line.
This will obviously have an immediate impact on how one might code for efficiency. Your code can be more verbose – there will be less need to build complex conditional statements that are barely readable in order to cram everything into one line of code. Not having to trade-off readability for efficiency will be very nice.
For the first time Apex developers will need to care about the efficiency of the built-in Apex class code. This will be a whole new topic for discussion, as the community gradually discovers which classes and methods are good, and which should be avoided, and when.
The real question comes down to what happens going forward – say, six to twelve months from now. Without the script limits, the pressure to optimize code will be reduced, and I’m sure we’ll see code appear on orgs that would never have survived in the current system.
As an ISV partner, this brings up an interesting question. What happens when some of that bad code, either on an org or in another package, uses up most of the CPU time, and when it becomes time for my package to run, limits are exceeded? Running a debug log with profile information should presumably allow identification of the greedy piece of code, but how many sys admins will take the time or trouble to actually figure this out? It’s so much easier to blame a package – possibly the one unfortunate enough to have tipped the CPU limit. As this occurs more and more often, one can envision a case where customers gradually lose trust in applications in general, never knowing if one can be safely run. Ultimately this could impact trust in the platform overall.
Arguments that the proposed CPU time limits are generous (and they are are), don’t (so far) address the well known fact that software inevitably expands to use available CPU time (often because it’s expensive to optimize code and therefore often not done unless it’s necessary).
There seem to me three possibilities going forward.
There is a real commitment within SFDC to build infrastructure to support inefficient code, so the performance will increase faster than the spread of inefficient code. (And don’t try to convince me that people won’t write inefficient code ).
The amount of headroom in the current CPU limits really is so great that it pretty much takes an infinite loop to exceed it. (I’m sure I won’t be the only one experimenting with this in days and weeks to come).
The engineers who made this choice are deluding themselves that all Apex developers will continue to write efficient code even when they don’t have to.
As an ISV partner who ships a very large application, I confess that the relaxed script limits are definitely going to make life easier. At the same time, I really hope that when CPU time limits are exceeded, they don’t just post an error blaming the application that tripped the limit, but rather more detailed information that explains to users where the CPU time went – so that it is easy for clients and vendors alike to quickly focus on the code or package that deserves the blame.
In my book Advanced Apex Programming, I spend quite a bit of time discussing trigger design patterns. But I’m going to let you in on a little secret – what you find in the book isn’t really a “design pattern”, so much as a design concept.
And despite the chapter name “One trigger to rule them all”, I didn’t originate the idea that it was a good idea to control execution sequence by using just one trigger – experienced Apex developers already knew this. What I think I brought to the table was the idea that we could take advantage of the Apex language object oriented features to implement that concept in some really good, supportable and reliable ways.
Here’s a secret – the examples I used in the book do not, in fact, accurately reflect the framework I used in our own products. The framework we use is considerably more sophisticated. But the examples do reflect the concepts that our framework uses.
I did this because I do not believe there is any one “right” trigger design pattern or framework for everyone and every situation. So my goal in the book was to demonstrate the concepts involved, in the hope that others would build on it – come up with variations of different design patterns and frameworks based on those concepts.
I was thrilled to see the other day a blog post by Hari Krishnan called “An architecture framework to handle triggers in the Force.com platform”. It’s beautiful piece of work (and I do appreciate the shout out). As with our own framework, I don’t think it’s a solution for every scenario, but it does present a very elegant object oriented implementation to the problem. What really struck me was the innovative use of dynamic typing to instantiate objects based on the object type and name. Our own framework doesn’t use that approach, for the obvious reason that it was built before Apex supported dynamic object creation by type, but it’s definitely worth considering for any design going forward.
I don’t know if Hari has worked on the .NET platform (he does mention Java and C#), but the idea of dispatching by name is one we’ve seen in a number of Microsoft frameworks and languages. One can’t help but wonder if, now that we have a real tooling API, someone might come up with a client tool to generate and manage trigger handlers based on a framework like this….
Not only might this automate some of the “plumbing”, but conceivably bring us to that state of Nirvana where, with judicious use of some global interfaces, we might be able to control order of trigger execution across cooperating packages and between packages and Apex code on an organization instance.
Ah well, one can dream. Meanwhile, kudos to Hari for a fine piece of work. Definitely worth a read.
A couple of days ago Matt Lacey posted an excellent article on developing for optional Salesforce features. He ended it with a question – how do you ensure code coverage for those orgs that have those features disabled?
For example – let’s say you have code that only runs when multi-currency is enabled on an org:
if(Schema.SObjectType.Opportunity.fields.GetMap().Get('CurrencyIsoCode') != null)
{
// Do this on multi-currency orgs
obj.Put('CurrencyIsoCode', o.Get('CurrencyIsoCode'));
}
How do you get code coverage for this section?
One way to do this is as follows:
First, we refactor out the currency test into it’s own function as follows:
Though not necessary for this example, in any real application where you have lots of tests for whether it’s a multi-currency org, you may be calling this test fairly often, and each call to Schema.SObjectType.Opportunity.fields.GetMap().Get(‘CurrencyIsoCode’) counts against your limit of 100 Describe calls. This function (which is written to minimize script lines even if called frequently) is a good tradeoff of script lines to reduce Describe calls for most applications.
Next, add a static variable to your application’s class called TestMode
public static Boolean TestMode = false;
Now the code block that runs on multicurrency orgs can look like this:
if(TestMode || IsMultiCurrencyOrg)
{
// Do this on multi-currency orgs
String ISOField = (TestMode && !IsMultiCurrencyOrg())?
'FakeIsoCode' : 'CurrencyIsoCode';
obj.Put(ISOField, o.Get(ISOField));
}
What we’ve effectively done here is allow that block of code to also run when a special TestMode static variable is set. And instead of using the CurrencyIsoCode field which would fail on non-multicurrency orgs, we substitute in any dummy Boolean field. This can be another field on the object that you define, or you can just reuse some existing field that isn’t important for the test. There may be other changes you need to avoid errors in the code, but liberal use of the TestMode variable can help you maximize the code that runs during the test.
Why use a TestMode variable instead of Test.IsRunningTest()? Because the goal here is to get at least one pass through the code, probably in one specialized unit test. You probably won’t want this code to run in every unit test.
With this approach you can achieve both code coverage and, with clever choice of fields and field initialization, functional test results, even on orgs where a feature is disabled.
