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

Join us in this episode as we delve into Robert Sösemann’s perspective as a Salesforce MVP and Technical Architect. We talk about the evolution from pragmatic coding to AI in Salesforce DevOps. Explore his journey, gain insights, and discover valuable tips.

Chapters

• 0:00 Introduction and Career in the Salesforce Ecosystem
• 3:05 Falling in Love with Salesforce's Simplicity
• 4:17 Expanding PMD: Analyzing Metadata Beyond Code
• 21:45 Exploring AI and its Potential in App Development
• 28:45 Start Experimenting with AI Now

Transcript

Harald (00:01)
I'm glad and honored to have another OG of Salesforce DevOps on the podcast today. Thank you Robert for accepting the invite and taking the time. really appreciate

Robert Sösemann (00:12)
Thanks Harald for having me.

Harald (00:15)
So Robert, I spied on your LinkedIn and saw, think your first Salesforce related job that hit my eye was starting in 2012. Could you share with us briefly your career in the Salesforce ecosystem, how it all started and how it evolved?

Robert Sösemann (00:35)
yeah, that's a long story. I studied computer science and had the normal career steps of a programmer. I worked a lot in internet companies. And at one place in my career, I was working for a Java consultancy and sitting in a very boring IBM training.

And, you know, it was, the time when, when, when people were very hyped by business process management, you know, drawing diagrams and trading software, like a kind of low code. And in that two day seminar, I was Googling a platform which I had worked on even years ago, which was, which was called Salesforce, you know, back then it was really just a CRM where you could change the color of buttons.

And then I found that this platform had dramatically increased with an app store, a programming language called Apex. And I basically went back to my boss and said, hey, we need to do this as a separate new business track. You know, build, I called it pragmatic business software using low code and Salesforce. At that time, I was also totally thrilled with Lean and Kanban and Scrum. And I made it. The company later became

a smaller German PDO and we were basically doing Salesforce, know, going to boring German companies and convincing them to trust the American cloud. And we even back then created one of the coolest free app exchange package. Maybe you have stumbled across it was called opportunity planning wall, like a candle wall where you could move opportunity cards

It was later stolen by Salesforce for their own Kanban view.

Harald (02:33)
But was it in classic still or?

Robert Sösemann (02:36)
Yes, yes, it was still in classic with Visualforce and jQuery, but this is how it started. And I totally 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. And in Salesforce, everything was like, there was one solution or no solution, and then you had to build around. I also, didn't program before.

I programmed during my university time, but then I became like managers and stuff like that. And then I really became to code hands -on and yeah. So, and I never, never left it and I never wanted to leave the Salesforce ecosystem.

This is.

Harald (03:23)
Great. yeah, so you also you're an MVP, are a frequent speaker, you publish stuff. And I think one thing that many people in the ecosystem associate your name with is PMD. So PMD, for those who don't know it, it's a static code analyzer, open source exists, I think in many stacks, right, very popular in Java, for sure, but also in other languages.

And I think, and correct me if I'm wrong, you were the person porting it to Apex first, but then what also not everyone knows, I think that you grew this into being capable even to do code analysis or static code analysis on metadata beyond code. So no code solutions like Flow or even doing things.

Robert Sösemann (04:17)
All metadata fields.

Harald (04:18)
PMD like checking if a field has a help text and things like that. So maybe you can share with us a bit the story, how it all started, how the idea came with you and then the process of launching this open source.

Robert Sösemann (04:32)
Sure. That was a fun story. So yeah, it was around 2015, so already nearly 10 years ago. I was working for a successful ISV in the up exchange space. And we were still a startup, but the development team grew. In the beginning, it was basically just me and a few guys who wrote the code. And we were

ambitious to make the code clean. But then there was the need to grow the team and we hired like students. And I wanted, as always, I wanted to control things. I didn't want to have to micromanage people, but still like enforce my quality standards. And I thought, wouldn't it be nice to have tools in Apex that I knew from Java, like code analyzers and yeah.

Then I thought, cool, what's there? And there was only one guy who has ported PMD with a, it's called CodeScan. It now I think belongs to AutoRabbit, but it was one guy in Australia. And I asked him, hey, can we like open source it? And he said, no, that's my money and like, sorry, I can't do it. And so a few students and I, looked into that and

we saw that it's actually easy to add new languages to PMD or it's doable. But the problem was the parser, you know, to PMD depends on breaking down the file and language into AST nodes, abstract syntax tree. And writing such parser actually was a bit too hard back then because we didn't know exactly how the language is. A few others have mastered it,

I just said, let's not do it. And then in a, under the shower moment, I thought there must be a parser and it must be in a way open source because the eclipse IDE, when I, when I opened a class, it shows, you know, there's this tree which shows methods and everything. And yeah, and then I looked into it and I've gotten into contact with Salesforce and yes, there was a parser. was closed source.

But we could repurpose it. Salesforce was really interested, gave documentation. And then we basically created a language model for Apex, which was able to do it. yeah, and then to make it actually usable, we took the Java rules and ported many of them, which apply to Apex from Java. that were basically, how do you say it in English, got the ball rolling.

And then I was, I think, invited to Dreamforce to have a speech there. Then all the IDE providers put PMD in there. And from then on, it basically never stopped to be like a topic. I never contributed as much code as back in 2016. From then on, I more tried to convince companies like Gear said, hey, can you please contribute? Or I was working for Copado and Copado

together with Manuel who works for you, we also contributed a bigger part to PMD. Right. And that's basically it. And at the moment, when you asked me what did you do in the last years, there was like two topics. One was working together with Salesforce, since Salesforce made PMD such an integral part of their own tooling.

And the other one, I would say last year and the years before was getting PMD on par with all the commercial tools. know, the commercial tools, always said PMD is not as good because it's only for APEX and Visualforce and not for the other stuff. And the other topic was it only works like static. It doesn't understand.

the runtime behavior across files. And this part was developed by Salesforce. It's called the graph engine. It's not part of PMD, but years ago we looked into, can we make that part of PMD? And it just didn't work out. So I didn't do a lot of that, but I was involved. And the other part was just making it possible to scan

XML which is the bigger part in a local platform and and this actually was not so much work because PMD is already able to do that and It just it basically needed conference talks and articles to tell people that they actually can do it and show them how to do it but Code wise in PMD. It was a simple thing. I hope

Harald (09:44)
And for what is the current adoption of metadata types where people use PMD rules to enforce certain quality? And is there even a limit? Could everyone come up with new rules to enforce whatever quality standards on any type of metadata where it

Robert Sösemann (09:58)
Yes.

polluting. I think in the Hutter template repository there is even samples of that.

Harald (10:15)
Absolutely, yes. There are a few metadata types covered, like common use cases that we hear from people we talk with. One that always raises an eyebrow is the ability to, for example, I mentioned it, have a very simple check to only accept or reject the pull request where a field is added without description and help text, because that is part of many manual review processes in Teams. And the idea to automate this is new to many.

Robert Sösemann (10:41)
That's a

Harald (10:45)
And I think it can turn out a huge win for a team to adopt such a relatively simple rule.

Robert Sösemann (10:51)
You can do it everywhere because everything which is not Apex, it's XML. It's always metadata XML. with the, you know, the most Apex PMD rules, are coded in Java, but the bigger power is actually to create custom rules in XPath and just have them as an XPath snippet in your rule set. And that not only works for Apex, this works for all XML. So

The most complicated one, which is not so easy, 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 an own Java code, but it's good enough. And really, we...

You can do it for everything. I've seen people use it for permission set, for profiles, for security settings. You know, the restriction is what do people actually put into version control? You know, you know, you don't know the coverage report that Salesforce is trying to get more and more states of an org into a metadata. And when you get that out, can, you can parse it and test it. So I would say

the imagination is the limit. And I just was at a conference in London, London's Calling and famous flow guy, Andy Engin -Utkan, he gave like a talk about flow -based practices. I really had, after the talk, I went to him and said, hey, we should implement them as PMD rules. The question is, do people who make a lot of flow actually get their flows into version?

That's a different question.

Harald (12:51)
That's the problem that we aim to solve, to make it really easy to open the world of Git -based development to non -technical or low coders, let's say. Right, super interesting.

Robert Sösemann (12:59)
Yeah, absolutely.

Harald (13:07)
with the, let's say, integration or adoption of PMD rules into what became the Salesforce code analyzer. Did that change anything? Do you think it helped the adoption of PMD rules with broader in the Salesforce landscape ecosystem?

Robert Sösemann (13:28)
Yes, I mean, it really, it really had made me happy because back then, when I was working at this PDO, really, we struggled with like check marks and we always hated it. I said to a colleague, maybe one day we will replace check marks. And when I ever talked with Salesforce, they like didn't say yes, but also didn't say no. But, but for me, the facts, they just look exactly like that.

checkmarks is not liked, it seems to be expensive for Salesforce under the hood, and now they replaced it and it's perfect. what's also really great, Salesforce could just have bought one of the commercial vendors, but they decided not to do it and just complete PMD with things that were missing like the graph engine, which does this dynamic analysis.

And I think this was a smart move. And for me, there's always like a little bit of, how do you say, cognitive dissonance between most people care about PMD because they care about security, you know, but honestly, I do not care so much about security. You know, those checks, is it with sharing? It was never my ambition. I wanted my developers to write simple code, clean code, you know.

The world, all the commercial providers, only mostly do this security narrative because it's easy. There is no deeper aid, know, security. yes, we need it. But when I come with clean code, there's a million haters who say, that's luxury. That's grumpy old white men with their books. And, but that's actually always my ambition. So, you know, security is important, especially on Salesforce, but there are so many people

care about this narrative, I don't want to be in that space. the code analyzer is still more a tool which checks things that are relevant for Salesforce to not risk reputation. But honestly, Salesforce doesn't care about well -crafted code so much. They tell the story of everybody can become a millionaire and a developer. So yeah. So I'm happy

PMD got so important in the Salesforce space because PMD is also a way to enforce the things that I care about. I hope that was not too fuzzy.

Harald (16:06)
No, that makes a lot of sense. yeah, think what now I really understood while you explained that probably also with this history of check marks, I mean, not everyone might be aware, but check marks was the tool that you were obliged to run when doing security review as an ISP to publish your work on AppExchange.

Robert Sösemann (16:27)
And now you don't need to do it anymore. Now you can use PMD.

Harald (16:30)
Exactly. And I, but what I think is important is that this tooling is not limited, of course, to this use case of ISVs who sprint towards reaching security review. But every Salesforce team, mean, even a smart team with two developers might benefit from going git base. And then I'm tapping this potential by having automated code reviews or assisted code reviews, which point out, I don't know, as you mentioned, then potential.

Robert Sösemann (16:58)
I do it all the time.

Harald (16:59)
or in a flow that might fall back on them later as their org scales or might just be to enforce simple good practices like certain quality challenge standards that they decide upon for themselves.

Robert Sösemann (17:08)
Absolutely.

Absolutely. I use it in my own private open source repository. So when you check my GitHub, I have a rule set in every root node and also in Akiva, the company I work for. We have an internal PMD rule set, which is pushed into every new repository. We do it for the open source things we do. It's a perfect thing. It's not tied to an IDE.

All the rules are actually in a file where you see the diffs, you know, you can check it and actually see how the rules evolve. You know, some rules are too opinionated and then you move them out and it's perfect. And I love it. And it's, it works everywhere with all the tools, know, and gear set, but also works in the IDE. That's, that's really, it's, it's simple, you know, it doesn't cost a lot.

But, and this is, I would say, always the biggest hurdle that I've heard in the last like nearly 10 years is, what do people do when they first time run PMD and then have like thousands of issues? And there's, that gets complicated.

Harald (18:35)
And do you have any advice? Would you advise to start with very loose or small rule set and then gradually build it out? Or is there any adoption? Let's think of a team that owns a Salesforce org. They work git -based and now they start putting automated quality checks. What would you advise as a strategy?

Robert Sösemann (19:00)
Yeah, the general narrative is often just to simply reduce rules, to not see it, but that's actually just leave them on. Don't feel obliged to do anything, but learn. would say running PMD and seeing thousands of issues is just, it mandates you to learn your development team. They should understand what, you know, there can be false positives,

There can also be like, in most cases, there's like thousands of instances of shitty naming conventions. And many people, they just say, let's ignore that rule, but why not just sit together for an hour in the team and say, hey, where this is actually our work? Why do we do so lousy work? You know, it's like when you write a letter to your mom and you mix uppercase and lowercase all the time in German. That's just

It's unprofessional work and this team could just say, we leave that on and we just fix it. That's my opinion. for sure, you should first look about the security issues. know, in PMD there is like a severity level which tells you is it critical or not. Yeah. But that's the part. People think,

I have to learn too much, have to understand too much, but that's the critical part. Coming into a position where you feel, where it feels safe to say we do that later, we ignore it, but we change something in the way we work now. And my impression is people just 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 less rules.

You know, when you pay money, you don't want to have pain. And that's the good thing with open source. I don't care about people's pain. I say, this is the pain that makes you learn. And that's the right place. Put the pain where the pain belongs. Yeah.

Harald (21:09)
Great. I'd like to touch upon one more topic and that is AI because you very obviously dedicated a lot of time to this topic. published a lot and I'd like

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. Like, yeah, we all know them, PromptBuilder and so on. So maybe you can just share a bit from maybe looking one, two years back, your journey

Robert Sösemann (21:54)
Cool. Yeah.

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

But as it never appeared in the Salesforce space, I could basically ignore it a little bit. But two years ago when GPT -4 came out and the world was on fire and in the crazy zone, I just took the opportunity to look a little bit deeper. And I was lucky that at Akiva, like our founders really took this very serious and they said, let's not just join the hype, but actually look into how we can make this useful.

for our work and our customers work and we founded an AI task force where we had time and money to do experiments and build some apps. So you probably have heard about my talks at Berlin and London and there's also a Salesforce Benardy where I talk about that. And that helped with two things. It got me and us realistic.

Generative AI won't destroy society, won't kill our jobs. It's less powerful than I thought in the beginning, but it's too good to ignore it. And yes, that's the thing. I honestly don't believe that the use cases that the world has found now are of big use.

creating more shabby email texts or summarizing terrible spammy emails. And the same with code, I still believe every line should be written by a programmer. If the programmer speeded up his work by using AI before to inform himself to think about designs, that's good. But every little character should be written by Harold, not copy and

That's my belief. And this is also true for blog texts, for books, for everything. The world should not see anything which is generated. It must go through a human who can act. Yeah, that's my opinion. So I really like it. I especially like this combination of old school code, deterministic apex code and AI to choose.

I'm not so thrilled by those email generation things or even rag finding things in vector databases. It's interesting, but not so much, but I really like this. 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 co -pilots and I think they will be a little bit the future.

Not sure if you asked that, but I often get asked that. I think it will change the way how we build apps. Because do you remember those times when all providers said we are API first before we build UI for humans, we build an API because then we can connect. I think maybe in the future, every app is

You know, you don't care so much about the UI and the use cases. You just build like mini tools, actions or skills. And then there's a general multipurpose user interface with language or text. And then the app just does what you'd invent, you know? Today the apps are maybe like a recipe or a restaurant where there's like three meals.

But in the future, it will just be like a good kitchen with a good cook. you just say, what do we have? We can do everything. So that would be my hope. Less app development and more creative. And that's also in the space where Salesforce is with low code. More people can actually come closer to computers and find out what they want.

Harald (26:39)
And concretely, knowing you are mainly working on the ISV side with being employed by a PDO who helps ISVs basically in their app development, knowing that not all of the work and tools that Salesforce has released are package -able yet, meaning usable by ISVs for their app exchange product, do you have any specific advice to

founders or tech leaders and so on on how to deal with with Gen .ai.

Robert Sösemann (27:17)
Yes, I do. But first I want to say Akiva is not only a PDO, we're also a huge S .I. partner. So many of our partners are just Salesforce customers and they also have a deep interest in how can we use Salesforce AI because Salesforce was very successful in making fear -based marketing by telling everyone you can only trust them, you know, with the trust layer.

I think that's a good story, but I think it's a little bit overdone. In the past, we also send Salesforce data over secure internet protocols to APIs. Why not do it now? The benefit of doing it with Salesforce is big because everything is declarative and everything is per default in a way safe. But as we all know, it also comes

with huge price tags, know, everything data cloud. And I also believe that it will take a while until all those things are super capable and stable or packageable. So we're just not there yet. And I think it would be bad if people just wait. They should get started today with doing experiments. And yeah, and I just recommend customers either

Asking us to help them or doing what we did like experiment with off platform AI, you know. We have built an open source app called myorgbutler, which is like a co -pilot, super capable, works much actually much better in my opinion. And it just uses open AI API. You know, it's also secure.

but it can do the same things. And as a partner, you don't lose much because you are still coding your actions in Apex and Flow as you would do for Einstein co -pilots. The only thing which sits in OpenAI is this moderation, the instructions, then the definition of which tools it can call. But I would say,

You could build and package such a co -pilot today with having 90 % of the code in Salesforce and having them unchanged in the future. And when Salesforce co -pilot comes out, you just move this little part from OpenAI into Salesforce. Yeah, so I recommend everyone to act now, to experiment now.

And just make the things in a way that you can later change the technology. Yeah, that's why.

Harald (30:20)
Maybe as a last question, is there any app you have encountered on AppExchange, no matter if you were involved or not, that excited you in that sense of going into that direction that you mentioned, not provide a menu with three items, but more having a more open -ended, maybe more conversational?

interface for users to achieve all kind of stuff through an app. Is there anything that

Robert Sösemann (30:49)
Yes, absolutely. I mean, I should not make marketing for other companies, but there is this one new ISV which wins all the demo gems one tight. You probably have heard about that. They have like a chat with your org and you you say, can you do that for me? And it just does it. That's really cool because

It basically helps helps doing declarative Salesforce even simpler. know, in the past, there was still, mean, you know, it just imagine things like Huta or GEEF said they also bring developer thinking into the world of admins so that they can do their work in a professional way. But think of they don't even have to cope with all those metadata artifacts. They just speak to an AI.

You know, that would solve instead of making the admins developers by teaching them DevOps, you just skip this whole part and have the AI build it in a conversation. So, so yeah, that's, that's, that's one, that's one thing that comes into my

Harald (32:09)
As long as the AI respects good practices and version control, I fully agree.

Robert Sösemann (32:17)
Yeah, but honestly, that fear of hallucination that ended quickly for us, we saw the more you give the AI like instructions, what Salesforce calls this grounding in reality, there is not much hallucination. So if you say use those instructions, it actually works. Yeah.

It's just not that you can, just an example from this, org butler that we build, you know, in my conference talks, I always make a demo and then I show, I go into the CRM and ask this in this chat window, Hey, I'm a sales guy. What should I work on first today? And sometimes it just translate that into a socket query looking for the earliest closing opportunity. But in some talks it

opens a list view where that data is also shown. And sometimes I thought, shit, my demo doesn't work. But then I thought, wow, it's actually creative. So sometimes these hallucinations also lead to new ideas of doing things.

Harald (33:32)
And very last question to round up. Do you have any vision of bringing the two topics we talked about together? I don't know, leveraging large language models in the world of code analysis PMD.

Robert Sösemann (33:47)
Good question.

Maybe multiple answers. It shifted. In the beginning, I saw that, ran OpenAI, ChachiBT on code and even posted on Twitter that OpenAI found more issues in code than PMD. So in the beginning, I was very much in the direction of maybe this will replace such clunky old fashioned tools.

But then I think it was last dream for us. talked to Daniel Balinger, the guy who runs Apex and Salesforce and they gave me a different twist on that. said, have a hope that PMD, no, they know that more code will be generated in the future by AI. So there will be even more risk that something doesn't work.

So, and they thought about PMD as a tool to safeguard this because only deterministic code, only like old fashioned clunky analysis can make that sure. So maybe PMD will become even more important as a fast and static way to check if code generated by developers is feasible. Yeah.

Harald (35:18)
So it will become part of a trust layer.

Robert Sösemann (35:21)
Yeah, yeah, maybe that. You know, it's always the thing that you do is very complicated and the check is quite easy.

That's my hope that I can still run this topic for some years.

Harald (35:37)
I think what could also be interesting is making the results more actionable to 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 prioritized action, that is something where already now I think a large language model might be helpful.

Robert Sösemann (36:06)
Absolutely. under, yeah, yeah. Understanding, understanding this list of thousand things, combining it, making recommendations. I think there should be enough information on the internet. So the LLM could actually come up with that. Yeah. That's good. No, but that should not become part of PMD. know, right. Let's, let's find a provider who makes some bucks by

Harald (36:29)
Right, that would be another layer on top,

Robert Sösemann (36:35)
putting a small LLM wrapper on top of PMD to do that. You could do it at HUT, you could. Hey! I would totally love it.

Harald (36:42)
Right.

Exactly, idea that came up. Alright, so yes, thank you very much, Robert. Great meeting you. Looking forward to meeting in person at one of the next events. Are you going to Dreamforce this year?

Robert Sösemann (37:04)
I decided not to go this year, but I hope to go and speak in Paris in December at the Insta. Cool. Thank you Harald for having

Harald (37:11)
Right, we'll definitely meet there.

Thank you very much. Have a great day. Bye.