From pragmatic coding to AI: The evolution of Salesforce DevOps (Trails Podcast episode #18 with Robert Sösemann)

Episode 18: Robert Sösemann, Salesforce MVP and Technical Architect

Watch me 🎬

Listen to me🎙️

I spied on your LinkedIn and saw that your first Salesforce-related job started in 2012. Could you share with us briefly your career in the Salesforce ecosystem, how it all started, and how it evolved?

That's a long story. I studied computer science and followed the normal career steps of a programmer. I worked a lot in internet companies. At one point in my career, I worked for a Java consultancy and sat in a very boring IBM training class. It was a time when people were very hyped by business process management, drawing diagrams, and trading software, like a kind of low code. In that two-day seminar, I was Googling a platform I had worked on years ago called Salesforce. Back then, it was a CRM where you could change the color of buttons.

I found that this platform had dramatically increased with an app store and a programming language called Apex. I spoke to my boss and said, "Hey, we need to do this as a separate new business track." I called it "Pragmatic Business Software using Low Code and Salesforce." At that time, I was also thrilled with Lean, Kanban, and Scrum. And I made it. The company later became a smaller German PDO, and we were doing Salesforce. We went to German companies and convinced them to trust the American cloud.

We even created one of the most excellent free AppExchange packages. Maybe you have stumbled across it. It is called Opportunity Planning Wall, and you could use it to move opportunity cards. Salesforce later stole it for their own Kanban view.

The other thing is that internal Salesforce teams like to test their metadata with the CLI. The CLI needs to know about their metadata, which may ship in the CLI six weeks before it's available to users. In doing so, internal teams are using the same CLI. We have to do a lot of releases besides those things. The other thing you'll see a lot is workarounds for server issues, where there's some new error, and it's returnable.

Was it in Classic still?

Yes, it was still in Classic with Visualforce and jQuery, but this is how it started. I fell in love with getting things done. I was often overwhelmed in the Java world. There was so much open-source, and it was changing too fast. In Salesforce, the mindset was that there was one solution or no solution at all, and then you had to build around that.

At that point, I hadn't programmed before. I programmed during my time at university, but then I became a manager and stuff like that. I learned how to code hands-on. I always stayed in it and wanted to stay in the Salesforce ecosystem.

You're also an MVP, a frequent speaker, and you publish stuff. One thing that many people in the ecosystem associate your name with is PMD. PMD is a static code analyzer. Correct me if I'm wrong, but you ported it to Apex first. I think you also grew this into being capable of doing code analysis or static code analysis on metadata beyond code. So, no code solutions like Flow. Can you share with us how it started, how the idea came about, and the process of launching this open-source?

That was a fun story. It was around 2015. I was working for a successful ISV in the AppExchange space. We were still a startup, but the development team grew. In the beginning, it was just me and a few guys who wrote the code. We were ambitious to make the code clean, but we needed to grow the team, so we hired students. As always, I wanted to control things. I didn't want to micromanage people, but I still like enforcing my quality standards.

I thought it would be nice to have tools in Apex that I knew from Java, like code analyzers. Then I thought, "Cool, what's there?" There was only one guy who ported PMD with what's called CodeScan. I think it belongs to AutoRabbit now, but it was one guy in Australia. I asked him, "Hey, can we open-source it? And he said, "No, that's my money. Sorry, I can't do it." A few students and I looked into that and saw that adding new languages to PMD is easy or doable. But the problem was the parser. PMD depends on breaking down the file and language into AST nodes, an abstract syntax tree. Writing such a parser was too hard back then because we didn't know the language.

Did you know that over 80% of Salesforce Developers believe that contributing to open-source projects like PMD, SFDX CLI, or other Salesforce-related tools significantly enhances their problem-solving skills and career opportunities? This reflects a growing recognition of the importance of open-source in professional development within the Salesforce ecosystem.

Others had mastered it, but I said we should not do it. In an 'under the shower' kind of moment, I thought there must be a parser, and it must be open-source in a way where the Eclipse IDE, when opening a class, shows you a tree of methods and everything. I got into contact with Salesforce, and there was a closed-source parser. But we could repurpose it.

Salesforce was interested and provided documentation. We created a language model for Apex, which could do it. To make it usable, we took the Java rules and ported many of them, which apply to Apex from Java.

I was invited to Dreamforce to give a speech. All the IDE providers put PMD in there. From then on, it never stopped being a topic. I never contributed as much code as in 2016. From then on, I tried to convince companies like Gearset to contribute, or I was working for Copado and Manuel Moya, who works for you. We also contributed a bigger part to PMD. When you asked me what I did in the last few years, there were two topics.

The other topic was it only works like static. It doesn't understand the runtime behavior across files. This part was developed by Salesforce. It's called the Graph Engine. It's not part of PMD, but years ago, we looked into making that part of PMD. And it just didn't work out. I didn't do a lot of that, but I was involved. The other part was making it possible to scan XML, the more prominent part of a local platform. This took little work because PMD is already able to do that. Conference talks and articles were needed to tell people they can do it and how to do it, but code-wise in PMD.

What is the current adoption of metadata types where people use PMD rules to enforce a certain quality? Is there even a limit? Could everyone come up with new rules to enforce whatever quality standards on any type of metadata?

Yes. I think in the Hutte template repository, there are even samples of that.

Absolutely, yes. A few metadata types are covered, like common use cases we hear from people we talk with. One that always raises an eyebrow is the ability to, for example, have a simple check to only accept or reject the pull request where a field is added without a description help text. That is part of many manual review processes in teams. The idea to automate this is new to many. I think it can be a huge win for a team to adopt such a relatively simple rule

You can do it everywhere because everything that is not Apex is XML. It's always metadata XML with Apex PMD rules coded in Java. The more extensive power is creating custom rules in XPath and having them as an XPath snippet in your rule set. That not only works for Apex but for all XML. The most complicated one is Flow. But in my example, I have a repository. It's called Unhappy Soup. There is an example which detects many cases of DML in a Flow loop. It's not as good as if we would parse it with Java code, but it's good enough.

You can use it for everything. People use it for permission sets, profiles, and security settings. The restriction is what people put into version control. Salesforce is trying to get more and more states of an org into metadata. When you get that out, you can parse and test it. The imagination is the limit. I was at a conference in London called London's Calling, where Andy Utkan talked about Flow-based practices. I told him, "Hey, we should implement them as PMD rules." The question is: Do people who make a lot of Flow get them into version control? That's a different question.

That's the problem we aim to solve – to make it easy to open the world of Git-based development to non-technical or low-coder team members. Did the integration or adoption of PMD rules into what became the Salesforce Code Analyzer change anything? Do you think it helped the adoption of PMD rules in the broader Salesforce ecosystem?

Yes, it made me happy because back then, when I was working at this PDO, we struggled with Checkmarx and hated it. I told a colleague, "Maybe we will replace Checkmarx one day." When I spoke with Salesforce, they didn't say yes but also didn't say no. It seems to be expensive for Salesforce under the hood, but they replaced it, and it's perfect. What's also great is that Salesforce could have bought one of the commercial vendors, but they decided not to do it and completed PMD with missing things, like the Graph Engine, which does dynamic analysis. I think this was a smart move.

For me, there's always cognitive dissonance, as most people care about PMD because they care about security. But honestly, I do not care so much about security. Those checks were never my ambition. I wanted my Developers to write simple, clean code. All commercial providers only mostly do this security narrative because it's easy. There is no deeper aid. But when I come with clean code, a million haters say: "That's a luxury." That's always my ambition. Security is important, especially on Salesforce, but so many people care about this narrative. I don't want to be in that space.

Not everyone might be aware, but Checkmarx was the tool that you were obliged to run when doing security reviews as an ISP to publish your work on AppExchange

You don't need to do it anymore. You can use PMD.

I think it is important that this tooling is not limited to this use case of ISVs who sprint towards reaching security reviews. However, every Salesforce or small team with two Developers might benefit from going Git-based. I'm tapping this potential by having automated code reviews or assisted code reviews, or in a Flow that might fall back on them later as an org scales to enforce good practices like certain quality challenge standards

I use it in my private open-source repository. When you check my GitHub, I have a rule set in every root node and in Aquiva, the company I work for. We have an internal PMD ruleset pushed into every new repository. We do it for the open-source projects we do. It's perfect. It's not tied to an IDE. All the rules are in a file where you can check and see how they evolve. Some rules are too opinionated, and then you move them out, and it's perfect. I love it. It works everywhere with all the tools and in the IDE. It's simple and doesn't cost a lot.

I would say the biggest hurdle that I've heard in the last nearly ten years is what people do when they first run PMD and have thousands of issues. That gets complicated.

Do you have any advice? Would you advise starting with a very loose or small ruleset and then gradually building it out? Or is there any adoption? Let's think of a team that owns a Salesforce org. They work Git-based and are now automating quality checks. What would you advise as a strategy?

The general narrative is to often reduce the rules to not see it. Don't feel obliged to do anything but learn. I would say running PMD and seeing thousands of issues just mandates that you learn your development team. They should understand what you know, and there can be false positives.

In most cases, there are thousands of instances of horrible naming conventions.

Many people say, "Let's ignore that rule," but why not sit together for an hour in the team and say, "Hey, why do we do such lousy work?" It's like when you write a letter to your mom, and you mix uppercase and lowercase all the time in German. It's unprofessional work. That's my opinion.

You should first look at the security issues. PMD has a severity level that tells you whether it is critical or not. But that's the part where people think they have to learn and understand too much, but that's the critical part. Coming into a position where it feels safe to say we will do that later, but we should change something in the way we work now.

My impression is that people don't want to do it. It's always this stress story. “I have too much stuff to do. I cannot care about PMD and all the commercial providers. They do it smarter. They have fewer rules.” When you pay money, you don't want to have pain. And that's the good thing about open-source. This is the pain that makes you learn. Put the pain where the pain belongs.

I want to touch upon one more topic, AI, because you have dedicated a lot of time to this topic. I'd like to hear from you what excites you about AI in the context of Salesforce without necessarily limiting it to the new products that Salesforce has launched. Maybe you can just share a bit from maybe two years back in your journey

As an intro note, my dad was also in IT and wrote his doctorate thesis about neural networks on those big computers in the seventies. I always heard about AI, but I thought it was too complicated for a guy like me who was not good at math. So, I feared this a little bit, and my dad always told me to go into that because that's the future. However, I could ignore it as it never appeared in the Salesforce space.

But two years ago, when GPT-4 came out, and the world was on fire and in the crazy zone, I took the opportunity to look deeper. I was lucky that at Aquiva, our founders took this very seriously and said, "Let's not just join the hype but look into how we can make this useful for our work and our customers' work."

But every little character should be written by a person. That's my belief. This is also true for blog texts, books, and everything in between. The world should not see anything which is generated. It must go through a human who can act. That's my opinion. So, I like it. I especially like this combination of old-school code, deterministic Apex code, and AI.

I'm not so thrilled by those email generation things or even rag-finding things in vector databases. They're interesting, but not so much. There is a little bit of AI and a little bit of code, and the AI chooses and parametrizes the right code. That's cool. So, I love those copilots, and I think they will be a little bit in the future. I'm unsure if you asked that, but I often get asked that. I think it will change the way we build apps. Do you remember those times when all providers said they were API first before building UI for humans? We build an API because then we can connect.

You don't care so much about the UI and the use cases. You build mini tools, actions, or skills. There's a general multipurpose user interface with language or text. The app does what you'd invent. Today, the apps are like a recipe or a restaurant, where there are three meals. But in the future, it will just be a good kitchen with a good cook. You say, "What do we have? We can do everything." That would be my hope. Less app development and more creativity. That's also in the space where Salesforce is with low code. More people can come closer to computers and find out what they want.

Do you have any specific advice to founders or tech leaders on how to deal with gen AI?

Yes, I do. But first, I want to say Aqiva is not only a PDO. We're also a huge SI partner. Many of our partners are Salesforce customers and have a deep interest in how we can use Salesforce AI. Salesforce successfully created fear-based marketing by telling everyone that you can only trust them with the Trust Layer. I think that's a good story, but it's a little bit overdone. In the past, we also sent Salesforce data over secure internet protocols to APIs. Why not do it now? The benefit of doing it with Salesforce is significant because everything is declarative and per default in a safe way. But as we all know, it also comes with huge price tags.

As a partner, you don't lose much because you are still coding your actions in Apex and Flow as you would for Einstein Copilot. The only thing which sits in OpenAI is this moderation and instructions, and the definition of which tools it can call. But you could build and package such a copilot today with 90% of the code in Salesforce and have them unchanged in the future. When Salesforce Copilot comes out, you move this little part from OpenAI into Salesforce. I recommend everyone to act and experiment now. Make the things in a way where you can later change the technology.

Is there any app you have encountered on AppExchange that excites you in the direction you mentioned – not providing a menu with three items but having a more open-ended interface for users to achieve all kinds of stuff through an app?

Yes, absolutely. I should not do marketing for other companies, but this new ISV wins all the demo jams, OneSight. You have probably heard about that. They have a chat with your org, and you say, "Can you do that for me?" And it just does it. That's cool because it basically makes doing declarative Salesforce even simpler. Just imagine bringing Developer thinking into the world of Admins so that they can do their work in a professional way. But think about if they don't even have to cope with all those metadata artifacts. They just speak to an AI. Instead of turning Admins into Developers by teaching them DevOps, you skip this whole part and have the AI build it in a conversation.

I fully agree as long as the AI respects good practices and version control

That fear of hallucination ended quickly for us. We saw that the more you give the AI instructions, what Salesforce calls “grounding,” the less this hallucination is. If you use those instructions, it works. For example, I always make a demo, then go into the CRM and ask this in the chat window: "I'm a sales guy. What should I work on first today?" And sometimes, it just translates that into a socket query looking for the earliest closing opportunity. However, in some talks, it opens a list view where that data is also shown. Sometimes I thought: "My demo doesn't work." But then I thought: "Wow, it's creative." Sometimes, these hallucinations also lead to new ideas of doing things.

Do you have any vision of bringing the two topics we talked about together? Leveraging large language models in the world of code analysis PMD?

It shifted. Initially, I saw that running OpenAI and ChatGPT on code presented more issues than PMD. I was thinking that maybe this would replace such clunky, old-fashioned tools. I talked to Daniel Ballinger, who runs Apex at Salesforce, and they gave me a different twist on that. They know that more code will be generated in the future by AI. There will be even more risk that something doesn't work. They considered PMD a tool to safeguard this because only deterministic code, only old-fashioned, clunky analysis, can ensure this. So, PMD may become even more important as a fast and static way to check if code generated by Developers is feasible.

So, it will become part of a Trust Layer

Maybe that. It's always the thing you do that is very complicated, and the check is quite easy. That's my hope that I can still run this topic for some years.

I think what could also be interesting is making the results more actionable for a team, for example. You mentioned the fear of having a lot of failures on your CI once you put your PMD quality rules in place, but to break that down to a team, for example, into a prioritized action, is something where I think a large language model might be helpful

Absolutely. There should be enough information on the Internet to help people understand, combine, and make recommendations based on this list of a thousand things. The LLM could actually come up with that. That should not become part of PMD. Let's find a provider who makes some bucks by putting a small LLM wrapper on top of PMD to do that. You could do it at Hutte. I would love it.

Evolve your DevOps

Thank you for tuning into this episode of Hutte's Trails Podcast.

Who would you like our next expert to be? Let us know on our LinkedIn page!