Thousands of companies have bought into the promise of Salesforce and are running their businesses in the cloud. The continuous innovation behind Salesforce gives forward thinking organizations the tools to develop custom business processes and applications that drive sustainable competitive advantage by removing the friction from customer facing business processes and making it easier for customers to do business with them. I have never been one to drink the Kool Aid, but I truly believe that just about any business problem can be solved with the Salesforce platform.
Unfortunately some companies will never see the full value from their Salesforce investment because of one problem that I have seen many times throughout the years that only seems to be getting worse: It is extremely difficult to find, hire and retain good Salesforce developers, and there isn’t enough of a backlog of new developers learning the platform to meet demand any time soon.
Salesforce is unique in that metadata-driven platform supports both declarative “point and click” and programmatic customizations. Salesforce developers get access to a database, powerful development tools and a cloud based infrastructure, and the proprietary Apex programming language enables developers to write code to leverage Salesforce as a driver of business innovation.
The challenge with the Apex language is that there is a steep learning curve for new developers, not only because the language is in itself highly complex, but because the Salesforce multi-tenant architecture is unlike anything most developers have ever experienced.
The complexity of Apex and the Force.com Platform presents a number of challenges for organizations that want to leverage Salesforce to run their business. The elephant in the room is that while there may be tens of thousands of developers on the platform, in reality a very small percentage of these developers have had the opportunity to spend enough time writing Apex code to become proficient in the language.
An even smaller percentage of developers have been fortunate enough to attend instructor-led training for classes such as DEV450 (Programmatic Development Using Apex and Visualforce) that not only teach the syntax of the Apex language, but give insight into how the platform works and provide best practices for designing, developing and maintaining Apex code.
The combination of a highly complex and relatively immature platform and programming language, coupled with the limited pool of experienced developers, is a challenge that many customers have to face in order to successfully implement and adopt Salesforce.
This problem speaks to the popularity of Salesforce and the rapid growth of the platform, but the reality is that there is still somewhat of a Wild West mentality with so many developers switching to Apex from more mature platforms and trying apply what they know from other languages without first taking the time to understand how Salesforce works.
This is a problem that keeps me up at night, because for every world class Salesforce implementation that I encounter, there are 20 more that have not even begun to scratch the surface of the value that Salesforce can provide. I have rescued far too many projects and have seen more than my fair share of horrific Apex code, and frankly I’d rather add value solving new problems rather than triage the same self-inflicted woulds time and again.
To help provide solutions to the problem of Salesforce developer scarcity, I am looking to leverage my unique position as both a Salesforce architect and developer instructor to show new Salesforce developers how to think about Apex and to help them add value faster.
I have had the privilege of training and presenting to thousands of Salesforce developers, and one of the things that I did not anticipate when I got into teaching is that my students are not the only ones learning learning; I also learn something new and I become a better Salesforce architect with each class that I teach.
With everything new that I learn from class discussions, the questions I am asked, or even just seeing something in the course material in a different light, I can apply deeper knowledge to my consulting engagements, and in turn take the patterns and best practices from the real world application of this knowledge back to the classroom.
I have found myself in the middle of a continuous, virtuous loop that benefits everyone involved and enables me to go deeper into Apex than I ever imagined. This knowledge loop is something that I want to grab hold of and use to publish design patterns and principles that can be shared with the Salesforce developer community.
Paradoxically, the deeper my exploration of Apex takes me, the more difficult it becomes to articulate my findings in a straightforward, accessible manner, and it sometimes takes weeks or even months to fully flesh out ideas.
There is, however, one overarching principle that I have found to be self-evident: Developers have to understand how the platform works before attempting to write a single line of Apex code if they want to be good Salesforce developers.
When developers from other platforms are thrown into the deep end and expected to quickly learn and apply Apex, the natural reaction is to simply learn the Apex syntax and apply design patterns and principles from the languages that they already know. This is a fatal mistake.
Anyone can read documentation, memorize syntax, and find code snippets on StackExchange to hack their way through an Apex development project, but any developer who wants to write effective and efficient Apex code has to first understand the underlying platform.
To understand the Salesforce platform is to understand why it is designed the way it is, how it works, and what can and cannot be done with it. Until there is a fundamental understanding of how this platform works, the power that lies within the platform can never be unlocked.
This realization was the result of many hours of research, reflection and discussion, and it radically changed the way I teach Apex and the way I approach Salesforce architecture. This is why I want to teach Salesforce developers how to think about Apex.
There is already a wealth of documentation and discussion on the “what” of Apex syntax. By teaching developers how to think about Apex, my hope is to contribute to solving the Salesforce developer shortage by giving developers a library of design patterns and principles that reduce the time it takes to master the Apex language.
My vision is to publish this framework as a series of posts that I am calling Thinking About Apex: A Salesforce Architect’s Perspective. There is currently a draft outline in place, and I will be publishing new topics each week from now until Dreamforce ’16.
To see where my head is at, take a look at the current outline and let me know what you think. This will be evolving over time, but after years of thinking about this (and years of writers block) it’s time to put a stake in the ground and make it happen.