Episode 050 — Wade Wegner: The birth and evolution of SalesforceDX!

Great to be here. Thanks for having me.

Well, do you have a good answer for that? I suspect it has something to do with my time at Salesforce building Salesforce DX.

You joined Salesforce in 2016. Tell me a little bit about when you joined and what it was like at Salesforce back then.

Yeah, it feels like a long time ago. In some respects, it has been. There were really two reasons why I even had the opportunity to join Salesforce. If everyone thinks back to 2016, the developer landscape and ecosystem for Salesforce was dramatically different. I'm sure we'll get more into that, but generally, there were certain things, particularly doing continuous deployment and continuous integration on the platform, that were pretty difficult. Two things happened that resulted in a job requisition getting opened that I eventually ended up getting hired for. The first was FinancialForce. If everyone remembers FinancialForce, Andy Fausett in particular had done some really clever things back in 2016. FinancialForce was doing a bunch of UI automation to create DE orgs so that they had brand new pristine environments, then they would install all their packages into them and basically run a bunch of their unit tests. They found a way to create what would possibly be more like the equivalent of having scratch orgs and a git-based CI/CD system that allowed them to automate a bunch of their testing. They did so by creating a bunch of DE orgs and running all their stuff against it. Honestly, kudos to them for figuring that out. I eventually ended up hiring Andy Fausett into Salesforce. I love the guy, still a tremendous friend. But that presented some problems. People may or may not know, and I don't actually know if this is still the case, but a DE org at Salesforce was actually running in a production pod. So what would happen is when FinancialForce would do this and then run all their tests, there were times that it would actually degrade the environment and affect production instances of customers. I think it even brought the pod down a time or two as well. So again, that's no good.

I mean, again, not casting aspersions on FinancialForce. They were doing the best they could with the tools provided. But it resulted in that. The leadership at the time was clearly thinking we need to make a change here because our biggest ISVs are trying to accomplish things on our platform and it's just too hard, and this is what they're doing and this is what it's resulting in. So that was one thing. And the second was in 2016, you can go back and look at it, Salesforce was listed as the number one most dreaded platform by developers on Stack Overflow. Dreaded platform, yes. The number one most dreaded platform by developers. So I used to joke that Salesforce loves being number one, but that's not one where Salesforce is really excited about it. So those were two backdrops to why the requisition and the opportunity even was created. And then I got just lucky enough, right place, right time, knew the right people, and I ended up getting the job. But that was just one facet of it. Even when I joined, a lot of work had been done and a lot of analysis had already occurred at Salesforce to start trying to build a perspective on what needed to change. So I was pretty lucky in 2016 to jump right in and get to work with the team.

Yeah, I think this is a really good leading question, which we didn't coordinate, but it sets this up pretty well. Even today, I'm sure Salesforce continues to be a little bit of a special snowflake. There are enough things that are unique, like even being a metadata-driven platform to some regard. There are not a lot of examples of other platforms that are out there like that. So it inherently will make some of the things unique and special to Salesforce. But back in 2016, it was a totally different unique development experience. If you were successful as a Java developer or a .NET developer and you had a set of experiences working in the industry, and then you switched over to become a Salesforce developer, it was a steep learning curve. There was very little skill set that you could apply from one part of what you'd done in the past to what you needed to do in the future. It's not entirely true, but generally, the whole concept of an org, an org being a combination of data, metadata, and code, just blows people's minds. Coupled with the fact that if you were used to using version control systems and working in environments with multiple developers, all of that changed. You had to rethink how you approached that with Salesforce. So I would say my background was very helpful in the sense that I was familiar with just the best practices that had evolved for software developers in general. When coming to Salesforce, a big part of this was, and I'll get to some of the cast of characters that I worked with in a moment, we had a set of core design philosophies which were centered around not being different, not being a special snowflake. We wanted people to be able to bring their experiences building elsewhere and leverage them within Salesforce to be productive faster. So we wanted there to be more corollaries to the kinds of things that developers already knew within the Salesforce platform. One other thing I'll highlight is I also have a consulting background. Prior to even being at Microsoft, one of the fun things about being a consultant is one week you're doing one project, then you're on the bench for a week, then you get assigned to do something else and you're sold as the quote-unquote expert. You have a week, it's like here's a book, Wade, read this, we're billing you out as an expert at this hourly rate, so you have to learn fast. I had some exposure through all of that to Salesforce, which meant that I didn't come to Salesforce without some fundamental background in interacting with the Metadata API, packaging, Apex, and things like that. Not to say that I was an expert by any means, but I had at least a baseline.

I'll also say I knew a number of folks. A lot of your listeners may remember a gentleman named Adam Seligman. He was a GM of the platform at one point, he ran developer relations, he was one of the original creators of Trailhead. He had an incredible career at Salesforce. Adam Seligman and I knew each other from Microsoft before he went to Salesforce, and he had invited me at one point to come to a hackathon where I got to meet Dave Carroll and Pat Patterson, who's also known as MetaDaddy. Pat Patterson was an incredible evangelist back in the day. That team built so many really cool things. One of the things I remember Pat Patterson built, this is before I joined, probably 2014 through 2015, he built a Minecraft integration into Salesforce. I don't remember all the details, but basically he was able to build a house, and the house had elements that you could interact with that were all objects inside of Salesforce. Through the Metadata API, he was creating literally structures like buildings out of objects where you could interact with the data in Minecraft, and it was connecting to Salesforce. I just thought things like that were super cool. I tried it out myself and played with it. It was a great exposure to the Metadata API and learning about metadata and how it all worked.

I have a terrible memory for dates. I know I joined in 2016, but I think we might have spent like a year or so building before we really launched. So I don't remember exactly the dates to be honest.

Do you mind if I start a little bit before 2016? Because we can get a little geeky insider here, because a lot happened. I may have joined in 2015 or early, I can't even remember. But one of the things I alluded to earlier is that some work had already been underway for a little while. At Salesforce, there was a principal architect named Jim Wonderlick. Folks who joined keynotes and so forth at different times may have had an opportunity to hear from Jim. Brilliant guy, had been with Salesforce for a long time, really understood both how it was used and the thing that I always found fascinating is there are engineers building internally and writing Java code creating everything else that we interact with. Jim knew both sides of the equation extremely well. He was very well versed with how Salesforce worked internally. Jim had been assigned to work with FinancialForce basically after these outages or these incidents around CI/CD, and been tasked to figure out what is a better way for them to be successful. How do we make our largest ISVs successful building on our platform where they need to have the tools they need to control the outcomes that they care about without negatively impacting the underlying infrastructure? Jim ended up writing a brief, and that brief was called Project Janice. That was the name of his analysis. In Project Janice, a lot of the things that people think about and relate to Salesforce DX were conceived originally. Scratch orgs, the scratch org concept, was born out of Project Janice. It was born out of this recognition that teams needed pristine environments that you could just throw away when you're done, disposable, one-time use type of environments. Originally, scratch orgs were really envisioned to work hand in hand with packaging, and this is where second-generation packaging as a concept came into play, which also brought in this idea of source-driven development as well. All of your source can be expressed external from an org, committed into a repo, and then have a set of tools that you could use to generate packages to deploy into orgs. Project Janice really codified a lot of the fundamental principles that ended up eventually becoming Salesforce DX. But I'll note that because Jim was working with FinancialForce, there was a very heavy ISV dimension to it. A lot of the early work around Salesforce DX was not meant to initially replace the entire developer experience, but it was really focused on how do we get ISVs with packaging more successful. When I joined, that's the world that existed. By the time I joined, Jim had already identified a bunch of the teams that needed to work on this, along with a gentleman named Doug Scott, who was the head of platform engineering at the time. Jim worked with Doug Scott, and Doug Scott and my boss, who was eventually or who became my boss was Adrien. Doug Scott and Adrien had gotten the buy-in from basically whoever they needed to at Salesforce to make sure all the teams that needed to work together to make this vision a reality all got organized into one engineering and product organization. Scott Musen was my counterpart on the engineering side. Jim Wonderlick was our architect, Scott Musen ran engineering, and I ran product. By the time I came in, it was really pretty amazing. We basically had all the teams and everything we needed to own our own destiny, which was just incredible. We were able to move pretty fast. One of the things that I really appreciated about Scott Musen is building at Salesforce, not only are you building net new things, but you're responsible for maintaining existing things. Almost every team at Salesforce is responsible for fixing bugs or dealing with whatever normal workloads, maybe requests from customers that you need to work on, and they bump the queue. One of the things Scott Musen ended up doing which was great is he organized his teams so that some of the teams carried maybe the lion's share of the burden for doing a lot of the management of different things like maintaining the Metadata API, and he created these new teams that were not encumbered by anything that existed and were purely focused on innovation. That really enabled us to move pretty fast. Some of those early teams, the scratch org team was pretty much a net new team. They pretty much only worked on building scratch orgs. There was a team that eventually built the CLI, and all they were doing was building the CLI. And we had a team working on source-driven development. We ended up creating a bunch of those teams, and we were able to move pretty fast on a number of dimensions. Eventually, we got to the point where after we did a review with Benioff, which is a fun story, we got through a bunch of those internal reviews and found ourselves before Dreamforce with the opportunity to showcase this. It was still pretty early, but we did open it up as maybe a preview or a pilot. We had scratch orgs, we had CLI, we had the basics for moving metadata in and out. It was a great starting point for us at that Dreamforce.

I guess maybe there's some skills, but I'd say more than anything, what is necessary is having a very detailed and strategic plan along with really great alignment across all the functions and really great mechanisms for rapid iteration and diffusing all the information you need to all the right people. We had amazing TPMs, technical program managers, who were at the heart of every single thing that we were doing across all these teams. We used to have what they called PCTs. I don't remember what it stood for, maybe it was a program committee team or something. The idea was because Salesforce at least back then, and maybe today, was highly functional. Engineering and product didn't meet organizationally until you got to Parker. There was a whole product management team, a whole engineering team, a whole design team. Very functional. To work as a team, you needed to create ceremonies and mechanisms that really required the right people to come together at the right time. We had these things called the Salesforce DX, well eventually originally it was called ACDX. When I joined, platform was App Cloud. Our original thing was ACDX, and it was like an AC/DC logo with an X instead. Our early CLI wasn't sfdx or sf, it was actually appcloud. You'd type appcloud. I don't remember if that was the case in 2016 to be honest, so I don't remember if we had switched it to sfdx already at that point. But originally the CLI binary name was appcloud. We used to have an App Cloud ACDX PCT every week. It was kind of a scrum of scrums, so to speak. We kept track of and talked through everything. One thing that helped me, and I'm sure other product leaders would find different ways with which they would be successful, but I'm a developer by nature. I was constantly building on the latest things. Back in the day, I had a lot of fun building plugins and all kinds of different things that pushed the envelope of what you could do. I was constantly iterating on what the teams were building, logging bugs, figuring out what worked and what didn't. We were very lucky that we had some early partners as well, like FinancialForce, that were also constantly trying to see if they could use everything that we were building to be successful. Having that cross-functional heartbeat to manage what we were doing, constantly using what we were building, working with customers, it was very iterative in terms of how we went about building and working on things. It also helped that at the time we were one of the more celebrated things even internally. There was a lot of excitement at Salesforce and across the platform for what we were doing. Benioff doesn't do internal reviews of developer stuff often, but even he cared about it. We found that really helpful too because if and when we had dependencies on other teams, we were able to point to the V2MOM and be like, hey, this is important. Generally, things would move pretty fast.

I think that's a part of it, but I think there's even something maybe a little more fundamental that I think is cool. I think people just geeked out on it to a degree and really thought it was kind of magical. Imagine you've been doing Salesforce for a decade or longer, and suddenly someone comes along and opens up a terminal. You've never really spent a lot of time in the terminal, maybe you've used the Ant Migration Tool back in the day. But then suddenly someone runs this very simple command, which I think is like sfdx force:create pointing to a definition file and hit enter, and within seconds an org is created. And you do sfdx org open, and now you open the org and it automatically logs you in because your credentials have been stored, and a brand new pristine org that you just created on the fly suddenly existed. People's minds were blown by this. Everyone was just familiar with sandboxes or dev sandboxes or DE orgs. Everyone was always worried about keeping their environment clean and pristine and not polluting it. The Trailhead team created this thing where you could create a Trailhead org and then attach all your DE orgs to it, because people generally would have like 80 DE orgs and you're like, where does that Apex code live? No one ever knew. So it just blew people's minds. It was a totally different way of thinking about interacting with Salesforce. There was an element of reveling in the geeky nature of it and what it represented.

There are a few. There are a few where I feel like I may have also personally had a little bit of a hand in it too. One of the early ones, I think I alluded to this App Cloud CLI early on. This would probably have been within the first few months I was at Salesforce. When we were building the CLI, it was getting built from scratch, a custom CLI built ground up. One of the things that I was very familiar with was Heroku at the time. I was familiar with the Heroku CLI and was a big advocate for us to actually, and this is pre-oclif not by much, but it is still pre-oclif. Oclif is the open CLI framework that Heroku created, and ultimately I think even today the sf and the sfdx and the Heroku CLIs are all built on oclif. I was a big proponent for basically using Heroku CLI as the foundation for what we were doing. Part of it was because of its plugin nature and the modularity of it. I was a big believer that the way that we wanted to do this was to treat the CLI as a set of plugins and modules that could be taken advantage of by developers and then extended by developers. For a while there, there was a proliferation of lots of CLI plugins getting built for Salesforce DX. The reason for it is you could take advantage of the authentication module and plugin and basically everything else that existed and just attach to it. You didn't have to figure out how to authenticate and connect to orgs or how to manage your identities locally. All that was managed for you. You could just create a plugin, take advantage of what was already there, and then just build your stuff off of it. People could just install your plugin. I was very happy. I won't say that that was a big battle that was fought, but there were definitely people who didn't want to go that direction early and they wanted to build something from scratch. I think we made the right decision there. Another one, I can't remember maybe you can remind me. At Dreamforce in the developer keynote in 2016, we showed the Force IDE, is that right? It was a Salesforce version of Eclipse that had been built for us because at the time we weren't doing VS Code. I can't remember if it was still just a terminal, but I think it was called the Force IDE. It was basically Eclipse that we had built so that you didn't really realize it was Eclipse, but we had built it as a thing for us to use that understood the CLI and other things. Anyway, long story short, we did a bunch of work and it just was not a great tool. It was not flexible, it was very cumbersome for our engineers to build what we wanted. At the time, VS Code was taking over the ecosystem. This actually required a lot of internal debating and alignment because at the time Salesforce and Microsoft have been like frenemies back and forth for a long period of time. I think we were in a period where we were not as friendly. It required a lot of approvals for me to end up getting it so that we could basically build a VS Code extension. I remember meeting with Shreni and Parker, and maybe I don't remember Mark being involved but I wouldn't be surprised if he was. Sarah Franklin was involved and became quite an advocate for it. We're talking months of internal debate and so forth. But finally, I think the right reasoning went out and we were able to move forward and start to build a lot of our functionality as an extension within VS Code. I think that was tremendous because even now, I know Karen Fidel is still I think leading Code Builder. There's a natural relationship between that decision and the ability to use extensions. VS Code is built on Monaco, which is open source. It really set the stage because our vision was to basically even build more of a web IDE using Monaco and everything else so that we had the ability to create this less experience whether you were in VS Code all the way to whether or not you worked in the browser.

Yeah, DevOps Center, Code Builder, all these things started early on. Part of my team, I'm trying to remember the tool the admins always used for deploying metadata from one org to another, change sets. My teams were responsible for change sets. Everyone hated change sets, but everyone was addicted to it. From the very beginning, ACDX and what we were doing for Salesforce DX first was very ISV focused. But I would say within that first year, we recognized that this is going to be powerful not just for ISVs but for basically all developers, even developers that work at companies that have very large internal Salesforce deployments. Even when I was there, we started working on Code Builder. DevOps Center all these things started probably around 2020. The thing that's interesting about Salesforce is eventually, I told you that Scott Musen was able to create these teams that were unencumbered by a bunch of other responsibilities. It only lasts so long. Once you ship change, once you ship scratch orgs and you ship all these things, before you know it you're responsible for the same workload. So innovation slowed down. Salesforce is such now, I don't know the details, but I would be surprised if DevOps Center had more than five engineers on it, maybe less, maybe more. What it means is you measure progress in multiple releases across multiple years. I saw recently that Rohit, Meta, and Deepti Berki, I still see things that they've recently shipped that we had started working on back in 2020.

Yeah, I mean, it's been a while. Second-generation packaging is a great example of something as well. Delip has been, I'm not sure what the status of it is if it's changed, maybe it's called something else now, but 2GP still exists. It was such a fundamental re-architecture of the packaging technology that it took a long, long time. It was very, very complicated. Plus, think about packaging. Packaging is actually a brilliant thing. Can you point to any other platform in the world where you've got this concept of a company has this org, again org is data, metadata, and code, and they can purchase and/or install code, data, and metadata from a third party, install it into their org, and then there's manageability rules that make it so that based on how it's been set up, you may not be able to screw their stuff up, they can't really screw your stuff up, yet it all works together. That is actually pretty amazing that this even works. I think it's a testament to the brilliance of the model and how it evolved over time. Honestly, to me, Salesforce was always way more interesting as a platform than it was as a CRM or anything else. That's powerful stuff. Now imagine trying to build a different model where the packaging infrastructure is more flexible because there were all sorts of things that ISVs wanted to be able to do that they just couldn't with the first-generation packaging architecture. Rebuilding that in the complex just took a long time, and it had to be very careful, very deliberate. You can't afford to screw this up along the way. People have sunk too much money investing and building these environments to risk some mistake going and blowing things up.

Yeah, there are always challenges when these fundamental shifts in how things work take so long. Eventually, Salesforce as a larger company has attention deficit disorder and switches year over year. What was neat for me is the first few years, maybe the first two or three years, there was a lot of support across all of Salesforce. It wasn't hard to get DX in Dreamforce keynotes and things like that because it was top of mind, it was topical, it was in the company's ram so to speak. But then the company gets excited about the next thing and the next thing. So CRMs became a big topic, and then I think I've heard that AI and agents are a big thing at Salesforce now. Part of the challenge is the company moves on, and you're still building to this roadmap. The megaphone highlighting all of the things that you're doing isn't necessarily working for you because it's highlighting other things. In the early days, what we were doing on the platform was aligned to what Adam Seligman or Sarah Franklin and everyone was doing on the evangelism side and the marketing side. It was an amazing partnership where the first few years everyone was kind of dialed into what was happening. All sorts of things were getting created on Trailhead and training resources. Even when I was there, it was less and less a part of the conversation. Advances are made, but probably not as much time spent on like, okay great, 2GP is a thing now, how do you migrate? There were probably some things that were missed along the way even when I was there to support easier adoption of what was built.

I don't know. In my time since, I've had different roles and so forth where my perspective has shifted a bit. Now I can look back and think about Salesforce, the larger Salesforce, it's got to continue to grow at a pretty massive rate to keep staying on top of things. You start thinking about where does Mark and where does the leadership team at Salesforce need to make their bets in order to keep growing at a rate that everyone expects them to. It's probably not a surprise that sadly the attention and all the investment goes to these new frontiers that have addressable markets that enable that kind of growth. It may mean that some of the true to the core stuff just, unless there's someone passionate internally, you know, and there are still some PMs on the platform that are fighting the good fight. Cheryl Feldman comes to mind. She joined I think shortly after I left because she was always part of the community and then I think joined as a PM after I was gone. I think she's still fighting the good fight to try to get stuff done and move forward. There are other PMs doing the same, but it's a little harder to make dramatic change when you're constantly building the next new thing.

Two things that I've noted. I think Chris Peterson was still doing Apex or at least doing Apex and other stuff. I actually don't know. Chris Peterson was the PM for Apex when I was there. One of the things that he had wanted to do, and we had talked a lot about, he went to Heroku actually. Someone else is probably responsible for Apex though. But one of the things that we had started was we wanted to effectively create, I don't know, I guess we didn't call it an agent at the time, but basically we wanted to be able to have it create and write Apex code for you. Salesforce is sitting on the largest repository of Apex code in the world. Imagine fine-tuning an LLM on that. I feel like I saw something related to code generation around Apex. Didn't Salesforce deliver that? Or am I wrong? At any rate, that was a conversation that we had had in 2020. I think that is a really powerful potential application of what it is that they're doing. An agent built on a fluent understanding of Apex but also very familiar with your particular org, your metadata, your configuration, your features. That's super powerful. Imagine an agent that you can talk to and it can, you never have to build a flow again in your life. Which would be a good thing. I don't want to enter those debates, I always try to stay away from Flow versus Apex. My sister by the way, she still works at Salesforce and she's actually the TPM for Agentforce. I get an opportunity every now and then to hear about what she's doing and keep on top of things. The potential for AI agents autonomously doing all sorts of things for us in the future, and this is the thing Salesforce has always done well. Think about the AppExchange. Why is it so powerful? Because it's a trusted app store. The emphasis Salesforce puts on trust is so powerful. Why should I trust installing someone else's metadata in my org? That could be terrible. Well, it's trusted, it was code scanned, reviewed, security reviewed, all those sorts of things. I think Salesforce brings that same lens and potential to this world of AI agents working autonomously. End of the day, it's a big trust question. What do you actually trust these agents to do? I think Salesforce, if they do it well, and I'm not here to say whether or not they are, but they are uniquely positioned to lean into this aspect of trust that is core to their identity. So I think that's interesting.

I've reflected on this a lot actually. One of the things that I really learned at Salesforce was how important it was for me to build an incredible working relationship with my engineering peers. To step back again, Salesforce is a functional environment. For the majority of the time I was there, I was working with someone named Scott Musen. I have no control over Scott. Scott is responsible for getting things done. He has leadership that doesn't report to my leadership. You go all the way to Parker or Benioff until they align. The ability to have this alignment and trust built between each other as peers where there's respect and so forth was fundamental. It wasn't a given. I had to earn it. I had to work hard to build that trust. I definitely took that experience with me. I was the CPO at two additional companies and also had it set up in a functional model where there was either a CTO or an SVP of engineering that I worked with. Having learned that experience, I was able to bring it into the next few and really invest the time needed to make that a highly productive relationship. That's the first thing that came to mind, and probably one of the more useful lessons that I learned there.

No, thank you. I'll just say I was always a huge fan, both then and now, of Gearset and all that you've done to support the community as well and build great tools. One of the things that I remember most fondly is back in the day, it's probably changed now, I think you're a little bit bigger than you were, but you didn't really have a whole lot of marketing, certainly no outbound marketing. One of the things that you all did was these viral ways of taking all of the errors that you could potentially get when trying to do metadata deployments or any sort of it. You were all great at finding errors that could occur as a result of something happening in the platform and writing these great blog posts that ended up having great SEO. It was just a great front door into Gearset and proved to people that the tools you built actually could solve these sorts of problems. There was always that focus on demonstrated value, which I respect and appreciate. It was very similar to the approach that we took, which is we really wanted to just deliver value and solve problems. So it's an honor to be on your podcast.