Bonny Hinners is a Senior Member of Technical Staff at Salesforce. In this episode, we sat down and talked about our shared love for test-driven development, what it is, how you can utilize it, and how it can improve your developer experience. After many years in the community and having been introduced to Salesforce with her work on a nonprofit, Bonny is now working at Salesforce. Her team works in conjunction with internal teams and Agile coaches with primary focus on process, improvement and experimentation.

Bonny discusses the importance of teamwork – learning about the code base together and preventing the silos – as there shouldn’t be any one developer who knows more about any part of the code.  

Listen to the show to learn from Bonny’s experiences that can help any developer process.

Show Highlights:

  • How mob development works
  • What test-driven development is
  • How to consider the role of unit tests
  • Test-driven development vs. acceptance test-driven development
  • The user doing the acceptance testing
  • The 3 basic ways an application can have a bug
  • The benefits of testing and retesting your debugging process
  • How to own your own Agile process
  • Why consider taking Bonny’s Pluralsight course

Links:

Episode Transcript

Bonny Hinners:
… and they needed a cloud-based solution, and Salesforce offered one for free, so I said, “Hey, can I implement this as part of what I’m doing for you all?” It was wonderful because every time a new need came up there at the nonprofit, I went to Dreamforce and saw that Salesforce was doing that, that it was part of the next release. I’m like, “You people are great. You’re figuring out exactly what I need right before I need it. This is awesome.”

Josh Birk:
That is Bonny Hinners, a senior member of technical staff here at Salesforce. I’m Josh Birk, your host of the Salesforce Developer Podcast, and here on the podcast you’ll see stories and insights from developers, for developers. Today we sit down and talk with Bonny about, well, honestly, our shared love for test-driven development, what it is, how you can utilize it, and how it can improve your developer experience. Now, after many years in the community, after being introduced to Salesforce with her work on a nonprofit, Bonny is now here working at Salesforce, and so we start by asking her about her current job.

Bonny Hinners:
My current job is awesome. That’s how I would describe it.

Josh Birk:
Nice.

Bonny Hinners:
I work for one of the teams that builds tools on the Salesforce platform for the developers of the Salesforce platform. So, it’s kind of inception in that way.

Josh Birk:
Because you’re using the platform to help the engineers build platforms so that you can help build tools to help them build the platform?

Bonny Hinners:
You got it.

Josh Birk:
Nice, nice.

Bonny Hinners:
My team works in conjunction with the Agile coaches here, so we’re very interested in process and improvements and experimentation and all kinds of fun things. So, we do test-driven development. We do mob development. It’s very fun.

Josh Birk:
So, that would be a good segue into the topic we’ve chosen for today, but I’ve got two questions first. First of all, mob development, tell me more.

Bonny Hinners:
Oh, mob development. We actually get onto a video conference for hours and hours in the day, and three or more of us will sit down with the code and decide what to do next.

Josh Birk:
Really?

Bonny Hinners:
So, in mob development there’s usually a navigator and a driver.

Josh Birk:
Okay, okay.

Bonny Hinners:
The driver is the person with the keyboard, and the navigator is the person being thoughtful, and everybody else is contributing ideas or looking up reference materials or just waiting for their turn, perhaps, if they’re just fully in agreement with what’s happening. Yeah, it’s pretty fun. You limit the amount of time that any person spends in any role, but hey, we don’t really spend a lot of times in those cycles of, “I’ve produced some code, and now I need somebody to do technical review on it,” and nobody wants to do it because I did something complicated, and now I’m off doing something else, and-

Josh Birk:
Else, yeah.

Bonny Hinners:
… they’re building their code, and they don’t really want to take time away from that, because they’re on that same two-week deadline that I was on.

Josh Birk:
Interesting.

Bonny Hinners:
Yeah.

Josh Birk:
So, it’s kind of like an organic productive version of a technical code review?

Bonny Hinners:
Except we still do all the processes. We still get to-

Josh Birk:
Gotcha.

Bonny Hinners:
… a code review, and we still make changes in our code where I’m like, “Maybe we should’ve done this differently,” or, “Oh, hey, there’s that thing we forgot to take out or put in,” or-

Josh Birk:
Got it. Nice, nice.

Bonny Hinners:
“… Let’s capitalize the first letter of that comment.”

Josh Birk:
Nice.

Bonny Hinners:
It all is possible still, but we kind of all do it together because we’re a reasonably small group. It’s pretty easy to do that.

Josh Birk:
Gotcha.

Bonny Hinners:
We’re also a new team, completely new, all new this year, but our code is old, so we’ve adopted code that had been managed by multiple teams prior to us coming onboard.

Josh Birk:
Got it. Got it.

Bonny Hinners:
So, it’s great because we’re all learning about this code base together. We’re kind of preventing the silos as a result. Yeah. There shouldn’t be any one developer who knows more about any part of the code base than anybody else.

Josh Birk:
Part of the code, yes. Yes. Back when I was a development lead, I always told them that I was trying to develop myself in ops lessons, and if I was… I hate to use this analogy because it’s kind of corny, but it’s like if I got hit by a bus that day, they should be able to complete the project without me. So, I appreciate the not having the one person who knows those three classes, and without them, you can’t get anywhere. So, I want to segue that into test-driven development, but first, I always like to give a shout out to RAD Women whenever I can. How did you get involved with that?

Bonny Hinners:
Well, let’s see. Back when they first were getting started and prepping for their very first round of coaching, I knew the folks who were putting the program together, and they were reaching out to women that they knew that were programming on the platform, and I was fortunately enough to be asked to participate. At first-

Josh Birk:
Nice.

Bonny Hinners:
… I was skeptical because I’ve always worked with a lot of men, and I thought, I’m not sure if I even know that this is needed, but hey, I’ll give it a try because, why not?

Josh Birk:
Right, right.

Bonny Hinners:
I mean, yes is always the best answer, maybe. So, I joined even with that bit of skeptical-

Josh Birk:
Skepticism, yeah.

Bonny Hinners:
… skepticism, even with that bit of skepticism in my brain at the time, and it was the best experience ever to get to meet-

Josh Birk:
Nice.

Bonny Hinners:
… a lot of women who were technically excellent, all of the other coaches that I met and got the opportunity to work with because we co-coach, and then all these women who are coming up as advanced admins who are interested in learning how to communicate better with developers, how to develop a little bit themselves, how to help troubleshoot when issues come up.

Josh Birk:
Nice.

Bonny Hinners:
It’s just a really wonderful community of people and ideas.

Josh Birk:
Nice. Yeah. No, they do amazing work, and I’m always happy to try to give a little pointer over to them whenever possible.

Bonny Hinners:
I was just going to point out that as a coach, I get to influence the way people think about programming, and I do take advantage of that to promote test-driven development-

Josh Birk:
There we go.

Bonny Hinners:
… to all of the folks that I interact with, because it’s a very life-changing kind of approach to development, and particularly for new developers, if you can get that new habit from the beginning, I think it’s really helpful with the RAD Women learners.

Josh Birk:
Yeah.

Bonny Hinners:
Often, they’re faced with this blank page syndrome, which is the same thing that writers get, and when you were working on papers as an English major, you might remember that. I have to fill out all these pages, and I know that I want a finished product that’s something like that, but where do I start?

Josh Birk:
Right, right.

Bonny Hinners:
If you’re using test-driven development, it’s super easy to figure out where you start. You take one of your acceptance criteria, hopefully it’s written in a given when/then format and given some user, some piece of data, some scenario setup. When this thing happens, they push a button, some new data comes in, then the expected output is this. Something gets saved in the database, something gets changed in the database, whatever that result might be. Hey, that sounds like a test.

Josh Birk:
That sounds like a test, yes.

Bonny Hinners:
… if we’re not thinking about unit test. Let’s dismiss the idea of unit test, which I think is a myth on the Salesforce platform anyway, for the most part, because there’s 20 things that happen when you save a record into the database, or update it, 20, 20 things. How do you get to one unit of that without touching all the other units if you’re actually interacting with the database? When you don’t-

Josh Birk:
No. Yeah, you really don’t.

Bonny Hinners:
To do a unit test, you do the mocks. You avoid touching the database. You do everything. You work really hard to isolate things, but then, how do you know that your system meets the business need? Because you’ve isolated everything so much, is there some flaw that happens when all the things interact, when all the steps come together?

Josh Birk:
Yeah. Well, first of all, thank you for the segue. That was brilliant. Also, I definitely appreciate the whole blank page aspect, especially to people who are coming in new to the platform, because I think the kind of coding that I had done prior to Salesforce, we had test scripts and stuff, but I don’t think the concept of actual unit testing and code coverage had really been forced on me in the way that Apex forced it on me as a developer, and I kind of that initiation, like a lot of developers did. It’s like, oh, well, Salesforce is forcing me to have 75% code coverage.

Josh Birk:
So, suddenly that became the goal. The goal was have this thing have code coverage, and as people have learned, for instance, code coverage is not the greatest metric of how well you’re testing, and then I had that kind of aha moment myself of, oh, wait, with test-driven development, I’m not catching up with the code and trying to figure out how it’s flawed. I’m starting with the problem that the code should be trying to solve, kind of thing. But first, let’s take a step back. What would be your elevator pitch? What’s your short description of what test-driven development is?

Bonny Hinners:
Oh, that’s a tough one. Elevator pitch? I don’t know if I can give you an elevator pitch, but I can tell you my story about why I chose that as my preferred method of development.

Josh Birk:
Okay, okay.

Bonny Hinners:
Like you, I started on the platform and went, oh, my god. I have to write tests. What does that even mean? Because I had written in Pascal and BASIC and a similar language, and I didn’t need tests. I ran it, and if it worked, it worked. So, that was a new concept for me when I started programming in Apex, and it was always hard because I took the approach that I had learned in my previous jobs, and in college and in high school, and that was you write the code that does the stuff, and you see that it compiles first.

Josh Birk:
Sure.

Bonny Hinners:
If you got past that-

Josh Birk:
Job one.

Bonny Hinners:
… then if it runs pretty well, you’re fine. This was a new concept. It was write all that, and then go back and prove that the things that you wanted to achieve got achieved, and to me, that was hard because I wanted to get the code coverage. I wanted to prove that my code did what I wanted it to do, but I wrote my code wrong to make it… Yeah. Testing was hard. It was a hard thing to accomplish. Then I went to a Dreamforce session that was like 15 minutes long, and I swear, they just stood up there and pretty much said, “Yes, test-driven development, you come up with the test, you write it so that it fails, and then you write the code that makes it pass, and then you run it again, and voila, you’re done, and you just keep doing that over and over again.”

Bonny Hinners:
They did a better job of selling it than that, but that’s the crux of it, and it was only 15 minutes. I went up to them afterwards and kind of asked the stupid question of, “But wait, there’s more, right? Then what?” They’re like, “No, really, it’s just you write the test that fails, you write the code that makes it work, and then you move on to do the next part of your code, what does it need to accomplish? You write that test,” and I was just like, “Okay. I think I can get my head around this,” and walking out, one of the other audience members said, “Well, that was life-changing,” and we were both like, “Yes, it actually was, because now I need to figure out how to do this.”

Josh Birk:
Yeah.

Bonny Hinners:
Luckily, I then started working at UnitedHealth Group, and their development strategy is acceptance test-driven development, and that’s when it all fell into place for me. I like, now I totally get it because I can put my Agile processes together with my development processes, and I can actually figure out how to write code that’s actually testable, and then actually serves as documentation for what the heck my code is supposed to be doing.

Josh Birk:
Right, right. So, let’s take a step back again because when I was kind of poking around for source material for this, it was very difficult for me to find the proper distinction between simply test-driven development and acceptance development, or test-driven development. So, what is the distinction there, and maybe tell me a little bit more about how that hooks into the Agile methods.

Bonny Hinners:
Okay. That’s a good question. Let me see. So, how would I differentiate acceptance test-driven development from simple test-driven development? I guess with test-driven development, if you don’t take the approach of acceptance test-driven development, with test-driven development, you’re kind of open to I could start with anything first, and that puts you in the mind frame… Well, it put me again in the mind frame of, well, what do I want my code to do first? So, then I’m circling back around that blank page a little bit, whereas if I start with acceptance criteria, and if I’ve convinced my team to write acceptance criteria in a given when/then format, then I have everything I need to write a test.

Josh Birk:
Got it.

Bonny Hinners:
I have the scenario, the data, and the user that I need to be able to do the test setup, and that’s the given portion of my given when/then, and I have the then portion, so that’s going to be my system assertion, and that’s going to fail when I write that test because there’s nothing in the middle.

Josh Birk:
Nothing to-

Bonny Hinners:
There has been no when happening.

Josh Birk:
Okay.

Bonny Hinners:
So, now I need to figure out, well, what does my code need to do to satisfy the when? If you are fortunate to get small enough and discreet enough acceptance criteria, then you get a nice suite of tests, but those aren’t all the tests. Right?

Josh Birk:
Mm-hmm (affirmative).

Bonny Hinners:
I still might be doing something really tricky with the Apex code, that maybe it’s using a new method that is part of Apex now that wasn’t part of Apex previously, and maybe I’m not that familiar with it, or maybe it’s just something complex that I haven’t tried before, and I want to make sure it works. Well, I’m going to code that in as small a block as possible so that I can actually test it. It’s the same way… Actually, I apply this to learning how to take advantage of new features in Apex. If I can write a test to demonstrate for myself what it does, what it doesn’t do, even understanding the platform in general, understanding where am I going to hit limits, for example, well, if I write a test that pushes the limits, then I can better understand how limits work. So, now every time I sit down to code, I sit down to write a test.

Josh Birk:
Interesting.

Bonny Hinners:
Then I go from the test… If I have a test that does something interesting, I can grab the interesting part and shove it into a method separate from my test.

Josh Birk:
Right, right. That’s an interesting twist, I feel like, because when I was first getting into the religion of TDD, really embracing it, I think the first way it was described to me was you can start with your user stories, you convert your user stories into test-based scenarios, and then you build the code up in order to make those stories generally work. But the way you’re describing is actually, does not need to be attached to a user persona or a customer story or person X is going to try to do X, Y and Z. It’s more flexible than that, and in some sense, you could be the user who is doing the acceptance testing.

Bonny Hinners:
Well, sure, because there is still a place for unit testing, and there are still parts of the code that I write that I need to verify do the thing that I thought they did. You know?

Josh Birk:
Mm-hmm (affirmative).

Bonny Hinners:
So, there’s three ways that an application can have a bug. There’s probably more than that, but-

Josh Birk:
There’s at least three.

Bonny Hinners:
But the three basic ways are there’s a problem with the user’s story, it didn’t describe a scenario, an edge case, and therefore, the code doesn’t accommodate that edge case. Okay? Well, that’s a bug. You fix it because somebody says, “This happens when I do this,” and you go, “Wow. I never knew you were going to do that. Okay. Now I know. What did you want it to do there? Okay. I can make that happen,” and you fix that.

Josh Birk:
Right, right.

Bonny Hinners:
You write the test that shows that, in fact, when they do that thing, they get the result that you thought they wanted-

Josh Birk:
They wanted.

Bonny Hinners:
… because you didn’t know this happened.

Josh Birk:
Yep.

Bonny Hinners:
Now you have a new result, so we’re going to put that into our new test, see it fail, the code that makes it work, and voila, all of a sudden refactoring in. Bug fixing is super easy because we’re reproducing our bugs with our test-driven development approach. Then another way that they fail, not the user’s story being wrong, but the test is wrong. So, another way that code is buggy is that you’ve written the wrong test. Right?

Josh Birk:
Mm-hmm (affirmative).

Bonny Hinners:
That usually, hopefully, with test-driven development especially, gets caught before the code gets released, because you start writing a test a certain way, and then you realize that you’re testing the wrong thing. You’re just looking at the wrong thing.

Josh Birk:
Right, right.

Bonny Hinners:
So, my example of this in the real world is the San Diego Zoo. They have a campaign to benefit rhinoceros as an endangered species, and their campaign is save the chubby unicorn, because some of the rhinos have only one horn. The greater one-horned rhino, I think it is, has only one.

Josh Birk:
Gotcha.

Bonny Hinners:
Awesome.

Josh Birk:
Okay.

Bonny Hinners:
Save the chubby unicorn, and someone gave me a present that was an ornament that is from the San Diego Zoo, and it has printed on the side, “Save the chubby rhino.” It’s like, that was really excellent quality assurance. Somebody looked at that rhinoceros-shaped ornament-

Josh Birk:
And they’re like, “That’s a rhino. That’s a rhino. A equals A.”

Bonny Hinners:
Our test says if it’s an animal, then the label should be the name of the animal.

Josh Birk:
Name of the animal.

Bonny Hinners:
We’re changing this. They didn’t know… I mean, they were testing the wrong thing. They wanted to test, is it chubby? Is it part of a campaign? There was some other test that needed to go in there.

Josh Birk:
I just got to say that some poor marketing slash creative person must’ve just been so sad, because chubby unicorn is clever. That’s good marketing, and to pull that from somebody’s… Yeah. No, no. [crosstalk 00:22:03]

Bonny Hinners:
Yeah.

Josh Birk:
Yeah, yeah.

Bonny Hinners:
So, you want to make sure that you’re testing the right thing.

Josh Birk:
Test right things, yeah. Well, I’ve got to go into your first layer. Are you representing what the user wants slash will do? Back in my front end development days, it was the days of pop-up windows. Anything you needed to do from a… If you wanted to zoom in on a product or just look at the product image, everything was a pop-up window, and it was always this… We kept getting all this… The windows never behaved the way anybody wanted them to. They would be behind the browser, in front of the browser. They’d open in a tab, and they’d just… Misbehaving windows was just this constant source of feedback.

Josh Birk:
So, me and the designer, we got together, and we designed the most beautiful, in the page itself, modal window that worked every possible way we could think of, like you click off of it, it disappears. Everything we thought the user was going to do, it responded correctly. We patted ourselves on the back, and we launched that, and we got rid of all the pop-up windows, and then we got a flood of feedback from people asking us why we removed the comparison feature, and the designer and I are like, “What are you talking about? There is no comparison,” and then we realized people were opening a pop-up window on one product, going to another product page, hitting that, opening up another pop-up window, and then putting those two windows side-by-side. We had no idea that user behavior existed until we took it away from them.

Bonny Hinners:
Wow.

Josh Birk:
Then we got a flood of people that were like, “Why did you take this away from us?” So, then what we did was the right thing, which was to actually put in a proper comparison feature that actually worked within the website as intended. But I think it’s kind of nice how test-driven development can be paved on good intentions, but then can also be improved on and refactored again in good intentions. The problem there is just update what your acceptance status should look like.

Bonny Hinners:
Absolutely. Yeah, and testing and retesting and applying that to your whole debugging process helps you get better stories. It helps you get better construction to your program in the first place because you’re thinking about these bite-size portions that need to do these smallish jobs that are a portion of the bigger job so that you can move stepwise through what you’re trying to accomplish. Yeah.

Josh Birk:
I think it’s good to highlight that, because in a recent interview somebody also pointed out that if you have these small unit design tests, you’re probably also going to have the smallest footprint of code. This kind of feels like a way to trick developers into doing Agile, I got to say.

Bonny Hinners:
It shouldn’t be a trick. Having worked in the magazine industry, I have to say that Agile makes so much sense because we were putting out monthly magazines, and my cycle was to spend about… For one magazine, I was running their test lab, so I would spend four weeks per issue, but during that four weeks, I’m trying to receive product that I can test, so I’m reaching out to all these companies, asking them for all my future plans so I know what my roadmap is. Right?

Josh Birk:
Right.

Bonny Hinners:
I have a roadmap defined, and I’m gaining knowledge, if you will, to help me achieve that portion of the roadmap once I get there. I know what I’m doing for this issue, so I’m writing that, I’m sending that to an editor who will review it and make changes or suggest changes, and then somebody else will package it all up and send it to the publisher, and it’s released. Oh, my gosh.

Josh Birk:
Yeah, yeah.

Bonny Hinners:
It’s just like doing software, and especially software in an Agile process where you’re working on specific deadlines. You know what you’ve got to get done for this issue, if you will, and you know when it’s due. You know that it’s going to be reviewed by somebody else. You know it’s going to be put together by the release manager at a certain point in time.

Josh Birk:
Right, right.

Bonny Hinners:
You’ve got to meet those deadlines. So, I’ve got to say I love Agile too.

Josh Birk:
Well, I think Agile’s sort of interesting because I think some people shy away from it because it feels like there’s a lot of weight and process and dogma associated with it, but my example has been there’s not necessarily Agile done right so much as Agile done right for you. What is the process that meets what you just described, which is, how do we get those monthly magazine out every single month in a way that is going to be acceptance-driven, process-driven, but also, do we have to do everything that’s in the Agile workbook kind of thing?

Bonny Hinners:
Yeah, exactly. I think, sadly, there is dogma applied sometimes, but the thing is Agile’s a methodology, so it suggests using scrum and scrum ceremonies, and it suggests avoiding documentation. Who doesn’t like that? So, we don’t have specs anymore as a result. I remember early days in the industry, we worked from specs, and I don’t know who put the specs together that I was working from, but those usually landed in my lap, and I was given some portion of that spec to make happen. So, we said, “Gee, those specs take a long time to produce. Can’t we just write the code instead?” So, that’s what we’ve been doing thanks to Agile.

Josh Birk:
Nice.

Bonny Hinners:
I think that is one of the great benefits of it, is that it eliminated the need to put together a document that details how things are going to be done, and in the time that you create that document, the requirements change.

Josh Birk:
Right, right. So, shifting gears just slightly, you also have a plural site course with the great Dob Robins talking about test tips and test development, but for admins. Is there stuff from that course that you think, and I know that this… We can do your high-level hot tips kind of thing, but are there things from that course that might but useful for developers?

Bonny Hinners:
I think that I wanted to do that course primarily because creating the data to set up the scenario is one of the hardest things for developers because of those 20 things that happen when you save a record in a database.

Josh Birk:
Right, right.

Bonny Hinners:
I actually worked with a company where we got a new junior admin who came in very gung-ho and ready to make improvements, doing a great job, and ready to watch all the things, and she said, “That vendor who’s writing code for us and putting code in, they’ve done something wrong because our code coverage is down to 50%,” and I thought, “Well, that’s crazy because I’m the one reviewing their code. That can’t be.” So, I looked at the number, and when I looked at it, it was 0%, and I went, “Well, that can’t be because nobody’s even released anything between her coming up with a number and me coming up with a number, so let me look at some of these errors.” The new admin had put in validation rules for phone numbers-

Josh Birk:
Of course.

Bonny Hinners:
… that required parentheses.

Josh Birk:
Oh, no.

Bonny Hinners:
There was apparently not a developer in the world who puts test data together with parentheses in the phone number.

Josh Birk:
I mean, in our defense, it’s two whole more characters that I just don’t really need.

Bonny Hinners:
Exactly. Exactly. So, every single test failed at the point of setting up the data. So, luckily, I was able to point out the Salesforce formula best practices guides, which have examples of how to do a good validation rule for phone numbers.

Josh Birk:
For multiple formats.

Bonny Hinners:
Yeah.

Josh Birk:
Yeah.

Bonny Hinners:
We changed the validation rules, got things working again.

Josh Birk:
Got your code coverage back.

Bonny Hinners:
But it made me think, how do we get admins and developers working more closely together, because they’re both serving the sand end users, ultimately, they’ve both got the same goal, ultimately, and developers don’t need to know about data, really. I don’t know. Maybe I’m alone in that thought, but when I’m wearing my developer hat, data is the last thing I want to have to think about, even when I’m writing integrations, honestly. But when I’m wearing my admin hat, I know that I’m thinking about data all the time.

Josh Birk:
Yeah. Yeah, and it’s interesting because some of the stuff we’ve had on the show has been, “How do you mock your data?” Probably by the time this airs, I think we’ll have aired the [inaudible 00:32:03] data generator, and it’s like, they just want the data to be there, just be there, and let me just use it and not have to worry about it that much.

Bonny Hinners:
Right. So, a developer’s point of view on data is it can be anything, and as long as it fills in the blanks, and then they run into things like, well, somebody wanted you to put parentheses around your phone numbers or keep the values within this range for this type of data, and within that range for that type of data, and you’ve got a mismatch. That’s hard. So, what if we could give a way for the admins to create the data that the developer uses in the test?

Josh Birk:
Got it.

Bonny Hinners:
We have test load data as a function that will actually load a CSV file, and I think it’s kind of awesome. It does have some limitations, so I’m hoping someday it will be built out in a more robust fashion to support, say, multiple relationships between records-

Josh Birk:
Nice.

Bonny Hinners:
… more easily, for example. That’s kind of what I go into in the plural site courses.

Josh Birk:
Gotcha.

Bonny Hinners:
How do we introduce the idea to admins that they can be responsible for the test data, and they can keep it up to date-

Josh Birk:
Got it.

Bonny Hinners:
… and make sure it matches validation rules? They can now run tests that verify their auto-launch flows and things like that. I did a presentation at Dreamforce about using that technique to test slows, for example.

Josh Birk:
Got it. Nice. Well, I just love the idea of a validation rule breaking everything. The story is old as Salesforce itself, I feel like.

Bonny Hinners:
It is, and it’s one of the those 20 steps. Right?

Josh Birk:
That’s right.

Bonny Hinners:
We want all 20 steps to be able to coexist and get us from that given, through the when, all the way to the then. We want all of those things to come out at the end, and that’s how we know that our users are getting what they asked for and what they needed.

Josh Birk:
That’s our show. Now, before we go, I did ask after Bonny’s favorite nontechnical hobby, and I have to tell you, this one’s a first.

Bonny Hinners:
Trapeze.

Josh Birk:
Trapeze, really?

Bonny Hinners:
I do static trapeze for fun. I’m really terrible at it, and I have a very patient coach who enjoys the challenge of trying to teach me how to be better at the things I’m trying to do.

Josh Birk:
I want to thank Bonny for the great conversation and information, and as always, I want to thank you for listening. Now, if you want to learn more about the show, head on over to developer.salesforce.com/podcast where you can hear old episodes, see the show notes, and have links to your favorite podcast service. Thanks again, everybody, and I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.