We're all in it together, and we're trying to make the best system that we can, and we're all just humans. And we're going to make mistakes. And things aren't going to be ideal. I can trust you and you can trust me. From Tuple, this is Distributed, where we show how world-class engineers tackle the challenges of remote work. I'm Jack Hanna, your host. Let's get to the real
Hey everyone, today we're talking with Ryan Bergman, who is a principal engineer at John Deere with over 25 years of experience developing software. Ryan has stints at both startups and large companies alike, so... Diversity of experience really gives him a well-rounded perspective on what works and what doesn't. And in today's conversation, we're going to dig into Ryan's personal backstory, including how XP saved the first startup that he actually worked at.
how he approaches introducing extreme programming practices, having done it with countless teams before, as well as how he prefers to work today, highlighting some of those specific rituals, habits, practices that he's adopted and refined over the years. So, Ryan, we're psyched to have you on. Thanks for having me. Would you mind just sharing a little bit about your personal backstory and your journey to software development?
I started at a very young age. My parents got me a Texas Instruments 994A when I was... and started programming then you know throughout school I It turns out when I was an adult, I learned that I had ADHD after one of my kids had it, and I read the description and realized, oh, I think this is me. I think my child got this from me, which I found as an adult I didn't. You know, you get in this situation where...
Looking at college, I thought, oh, I don't know that computer science is for me because you have to take calculus and trig and all of these things. And in high school, I became more of an art student. And so I went into college as a graphic art major. I wound up switching majors into city planning. So I have a degree in community and regional planning.
And then after college, community regional planning is something you kind of got to move for. You got a lot of jobs in one particular area. You got to go work for some city. My fiance, my wife today, she had another year left. And so I knew some. people who are doing a startup. doing some tech stuff, and throughout college I had been making, this is the 90s, I had been making websites for my friends' bands and student groups and stuff, so I kind of joined this company to making
websites, and I never really went back. I just kind of kept doing tech stuff, and I kept being interesting, and I kind of worked my way from the front end backwards. And today, I mostly exist kind of like an API, a very raw layer. I don't work on a lot of UIs or anything I work on. APIs and integrations and systems of systems. I'm mostly a systems person today, so how do systems react to each other? How do we observe them? How do we
How do we get things to talk to each other? And how do we get large numbers of teams to be able to work together to make coherent products when you've got a tech stack that goes from a tractor all the way to web application development to mobile applications. And there's no such thing as a full stack engineer in that because the stack's too big. So that's kind of been my career. That's a very shortened version of my career, but that's kind of where I'm sitting at the moment.
I happen to know over the past year that you've Been getting back. into extreme programming practices. It's my understanding you were first exposed to extreme programming, XP, at that startup, GeoLearning, an LMS company back in the early 2000s. What brought that company to the brink? And then why was extreme programming what the engineering and technical folks turned to?
For people who aren't aware, a learning management system is basically the same kind of system you probably use at work to take compliant classes on things like sexual harassment or... whatever it is. So it's a big industry that was going through a lot of consolidation during that time and probably still We had been, when I joined, I was like the second tech employee, and we really grew it into a small company over 10 years. The first learning management system we had, we had bought.
from somebody just purchased the software and it was written in cold fusion, which was very common at the time around 2001. There was still a lot of cold fusion in the world. So there was a desire, though, to rewrite it into something that was more palatable to companies. You know, you get a lot of RFPs and stuff and they were like, well, it either needs to be Java or .NET.
or whatever there's lots of good reasons to want to like start a fresh foundation but when they did that they kind of we decided to contract out to us so we So we hired some architects and some developers who weren't working on the existing platform. And those of us who are working on the existing platform, well, that still needed to be supported and maintained.
And so you get into kind of a Zeno's paradox there with one team that's starting to build something fresh and another team that already has this big foundation. And it becomes this race because the team that's doing the original stuff, the older stuff, they're still adding features, right? And the new one has to catch up with it and then exceed it. And then the problem comes is that,
The people who are working on the older system, they understand all of the problems. They understand the customer's problems. So the customers are saying, hey, we need to do this, and we need to do this, or this is a problem, and this isn't scaling, and they can address those things. The team that's making the new thing, they don't have the domain knowledge. And so they end up making a lot of the same mistakes that were made on the original software.
and they just kind of recreate them. And we're not talking about, like, very obvious things, like, from the UI perspective. We're, like, kind of, like, underlying things. Like, How does iCal work? And things like that, because there's a big scheduling engine. It got to the point they'd spent a lot of money on that system. And this is a small company that doesn't have a lot of capital.
and we needed to go out with it. So there's several contracts dependent upon this new system. It has some new features that the old system doesn't have, and they're really necessary for these contracts. and we try to go out with it, and it's just, it's reeled with bugs. It can't scale. And so... The company kind of went through a period there where they knew this wasn't working. We needed to do something a little bit more radical. And so there was a change in leadership.
And the new CTO hired in some coaches from Object Mentor, which was Robert C. Martin's company. And so we had some very good... Very excellent coaches people who are really good friends of mine to this day That was very expensive for a small company, but we've essentially ceased ceased doing any work other than getting the system under wraps and we kind of
let go of the contract company that had helped build this new system and we took all of the old developers who were working on the existing platform and moved them onto the new platform. That means teaching all of those people how to go from cold fusion to to c sharp is what it was written in and there was all these bugs and stuff and so we really went back to
It was a full embracing of XP. So all stories had to be unit tested. Everything was pair programmed. There was behavioral tests and acceptance tests. Actually, we used fitness. which is an acceptance test-driven development framework. And it took us about, it took us like four or five months before we even were able to do any new features really at all. Other than maybe something that was very tiny.
The really interesting thing comes after that initial training. All these developers on these practices And keep in mind that our coaches are pair programming with us every day and teaching us how to do this kind of testing. But we extended that. We extended some of these ideas of XP and Agile and how we're delivering software and how incrementally we're delivering software. and started to apply it to project management and everything.
We had been practicing Scrum for a really long time, but Scrum itself is not Agile or XP. In fact, if you look at the history of Scrum, it goes all the way back, I think, into the 80s. You can do a waterfall project in Scrum. There's nothing necessarily agile about it.
It can be. It can be fine. But we kind of broke the system. You know, this is, again, a small company. We have about 30 engineers. And so we went to a system where we really didn't even have any teams. We had kind of three, what I would call kind of like tens of teams.
So there was kind of like a feature group, and then there was that one group that dealt only with how courseware runs, which is kind of its own weird little thing, sub-area. And then there was people who were working on kind of defects and very, very small enhancements. But the people are interchangeable in all those groups, and people float around depending upon need. And the feature group's not even really a full feature group. What it is is a story comes in, the product owner says,
I have this feature I want worked on. And so then we look at the people and we say, okay, who's somebody that knows this area of the code really well? We'll take that person and then we'll take another person, probably two other people. So we have four people, two pairs. Two of those people are kind of permanent on the feature, and two of those people are kind of rotate in and out out of those other pins every couple of days. That way we have a couple of people who are really driving the story.
and the feature and understand fully where it's going and what it needs to do. And then we have all these other people that are learning. about what the feature is so that when it goes out and when we finally release it into production, everyone has a good understanding or at least knows someone who has a good understanding of what this feature is intended to do. And so we would drive it through that.
And then we would disband that team. And so then the next feature comes in and we pick new people to work on the new things. And I think, and that for me was the most productive I've ever seen a group of software developers ever. How do you measure that? What made you feel that way? When you're on a really really good team that's really productive, you kind of feel it in your bones. You can gauge it against all of the other stuff that you're working on and all the stuff you've ever worked on.
And you can see as you're releasing stuff to production and you're turning stuff on and customers are getting those features and giving you feedback. I'm sure we had some metrics and stuff to add. But we weren't even using Jira or anything. We were just using sticky notes on a wall.
At the same time, we were doing some pretty crazy stuff with our backends and how we were deploying. We went through like four different version control systems in a year. We went from CVS CVS to Acurev, and nobody's ever heard of Acurev probably, but it was actually pretty cool. Subversion and then finally to Git and we ended up in Git and this was like in 2007 so Git was still pretty young and we were doing all all of these crazy things and it was happening so quickly
I shudder to think of like an organization like Deere trying to go through four or five version control systems in a year. There's just too many people. We have the advantage of having only like 30 people and we're all in the same room for the most part. We ran it like that for like a couple of years. And by the end of that, we were kind of dominating our segment of the market. So we were really chewing up the small and medium business.
segment of the learning management system, and we were taking business away from companies that were much, much larger than us. And eventually we got bought We sold ourselves to one of our competitors, which was one of the goals. This was either an acquire or be acquired kind of world we were living in. That company that acquired us didn't have all the same values as the company.
Geolearning did. Didn't necessarily see the value in things like pair programming. And over the course of about four or five months, most of the development staff quit. There was about 15 of us that ended up at Deere at the same time. John Deere was, or at least my division of John Deere Intelligence Solutions Group.
We work on the more advanced computing systems of the tractors and the guidance systems. A gentleman named Dean Luffingwell had come in and helped create that plan responsible for SAFE. as a framework, and SAFE is actually based on what he had worked up at John Deere Intelligent Solutions Group as one of his prototypes. So that kind of came from here. So they were really looking for a lot of people who had experience with Agile and XP. At the time, a lot of us came over.
all at once. There's lots of places you can go to work and be like, I'm going to do TDD and pair programming and everything. But if the business isn't supportive of it, you're not going to get very far. Could you help the audience orient a little bit about your current setup, your principal engineer? Do you sit on a specific team? Do you work across teams? What's the lay of the land of your role today?
Yeah, so there's an application that if you're familiar with farming, you might know about it. It's called John Deere Operations Center. That's the application that I work on. So this is the main application that farmers and or anyone who owns
John Deere equipment can use to, you know, we take all of the information that comes off of the tractors and the combines and stuff and kind of suck it up into the cloud and then turn it into maps and other resources. And then there's all these tools for... larger farm organizations, large and small ones, but the nice use case I like to tell people about to kind of explain it is You can go out and you can plant a field of corn, and then you can harvest it.
And we suck all that data in, and then you can look at a map, and you can see on it, oh, I get bigger yields over here, smaller yields in this area. I can send that information to an agronomist. and an agronomist can say okay well you need you need some potassium here and you need this other thing here And so they can write a prescription and the prescription goes back to you and it gets loaded into a sprayer or something else.
And then that sprayer can go out and it can drive in the field and apply exactly the amount of chemical you might need in one area versus another. And it is autonomous. So we work on kind of all that. And then Operation Center is where you can go and see all of this. And you can see, you can open it up, you can see a map.
of your farm and you can see the tractors like driving across it and you can click on them and do things with them. So I work specifically in the area of kind of APIs and third-party integrations. I work a lot with other companies. I'm kind of responsible for like all the teams need to kind of go through me at one point or another. Let's say there's a dozen that are actually producing API or producing something that I would need to have some kind of say in the governance.
And then there's many more of that that want access to our APIs, right? So they're doing something. So I work with them too. How do you use our APIs? How do you get the data that you need and want? from an xp standpoint you know i will i do enjoy pair programming still i don't always find a lot of great opportunity to do it, but I will certainly do it if somebody invites me. I kind of operate by vampire rules. What are vampire rules? You have to invite me into your house.
I don't like to come in and jump into a team and do stuff and then leave. I've done it. Sometimes you've got to do it, but I don't like to. And I don't think teams want me to do that. But if they invite me in and say, hey, Ryan, can you come and do some mob programming or pair programming with us and help on this? I'm all for that. I do a fair bit of programming of some of our... Okay, so...
There are... numerous teams that you support in your role as a principal engineer and you operate by vampire roles right like folks kind of bring you in to their situation into their world or their home when they need help with a variety of things, particularly related to the data layer or the API, how things communicate with one another.
And it sounds like through that, you've probably had the chance to collaborate with folks in a bunch of different ways, because each one of these teams probably operates in their own way, with some nuance, at least. And it sounds like you have preferences for some things, like when folks invite you to paramob your game, but it doesn't sound like you're very prescriptive in the way in which you work with some of these other folks. So I'm wondering if you go back. to your time at geo-learning and
Some of the coaches that you were exposed to then, I think Tim Ottinger was one of those coaches. What did that experience teach you about teamwork and collaboration that you've taken with you to the work that you do now? where you touch so many different teams across so many different work streams. The one thing that I really learned through all of that and one of the reasons why I kind of value
I value these practices so much is they're very in the moment. It's hard to get into things like gold plating when you're doing these practices, when you have a pair. and you have a story that you need to work on, and you're doing TDD. And so the TDD says, I've got to write a test to do this thing. And that thing should align to what my end goal is. left to my own devices and I think this applies to a lot of developers
left to my own devices, if I didn't have those structures, I could end up going down a rabbit hole and deciding that, you know, oh, this subsystem needs to be completely rewritten. It's just terrible. And it doesn't matter that that subsystem works, that nobody's complaining about the subsystem, that the only reason that I don't like it is because I didn't write it.
And I might have some legitimate concerns about it, sure, but that's a lot of wasted time. I've gone in my career down so many rabbit holes of that kind of thing, of reworking things and reworking them until I think that they're perfect. And those practices help contain it. And I think that's a lot of the productivity. And that's not to say that those kinds of things don't need to be done. Things need to get rewritten.
sometimes but it should be something that the group that the team decides not necessarily one developer deciding that something needs to be rewritten we need to collaborate as a team We need to have that constant feedback, not just from our customers, but from our teammates. And, you know, the thing I learned from Ottinger, And others was to do that in a kind and compassionate way, understanding that not everybody is coming from the same place. Not everybody has the same experience.
And there's always going to be something that's going to make you feel dumb. No matter how long you've been in this industry and no matter how experienced you are as a programmer, this technology moves too quickly. And you're always got to be learning from anybody. And you got to stay humble in that. You know, I'm a principal engineer, but there's stuff that junior...
engineers show me all the time and I'm like oh I didn't know that could do that. That's really that collaboration and that trust that you develop with a team that's practicing this stuff I think is in a lot of ways, the most important part, even more than the purely technical practices. It sounds like there's almost a mindset to it that allows you to be more effective. How do you go about building that trust and that relationship when...
You're working across so many different teams. Like I can reason about how do I build trust with my five person team that I work with every day. But when you have, it sounds like three teams that you work with almost every day and maybe a dozen or so more. that you work with sporadically. How do you go about building trust with those individuals who need to rely on you and who you rely on to get stuff done, but you don't interact with on a daily basis?
Yeah, that's been challenging. One thing I took from My time at GeoLearning was we were very involved in local user groups. There was, once upon a time, a ColdFusion user group. There is still today what we call CIJUG, Central Iowa Java Users Group. There's a .NET users group. And we were very involved at GeoLearning in basically any group that we thought we had any relationship with at all. and maybe some that we didn't. And we encouraged our own employees to talk at those
And creating that kind of environment, and we did that internally too, by the way. It wasn't just like, hey, let's invite everyone from the community to come here and talk about this cool Java thing that we did. It was internally sharing across all those teams. And we do that at Deere. It's gone through different iterations. So we have a number of different guilds. I've run them in the past. I've been trying to get other people to run them so that
You know, can't just always be the Ryan show. But I still talk at them. In fact, I'm talking at one next week where we're going to kind of go over the structured concurrency in Java 22, which is some pretty cool stuff. And that's how I stay connected with these teams, you know, because it is a weird thing. I've been very conscious of the fact that, you know, I'm now at a senior level in my career and a little bit older than your typical developer.
There's a possibility that, you know, people might be apprehensive about asking me something. They don't want to look stupid in front of the principal engineer or something like that. And I just try to take every meeting I have with trying to disarm that. I want people to be as comfortable with me as possible. I try to be selfish. deprecating to a certain degree that I've made mistakes. I've made lots of mistakes in my career.
Any architectural decision you make is probably wrong on at least one level. You know, when you're explaining to somebody, hey, you need to do this this way, and yes, these are things that aren't good about it. and we know that they're not good about it, and we would like to do something about them, but you can only work on so many things at once. But being clear with the developers that this is a joint venture journey.
We're all in it together, and we're trying to make the best system that we can, and we're all just humans. and we're going to make mistakes, and things aren't going to be ideal. I can trust you and you can trust me, then...
Then we'll get somewhere together. Oh, that sounds like If we were to get really tactical here, that being self-deprecating and sort of pointing out some of the mistakes or acknowledging that you make mistakes too is something that you've done to help others feel comfortable with you so that they don't feel like they...
have to hide their own mistakes or put a face on and have some sort of inauthentic interaction. What are some of the other tactics that you've successfully used to make other people feel comfortable working with you, given your seniority and the fact that, again, you're not working with folks every day. I think pair programming is a perfect world to do that kind of connection with somebody because you really can just sit down and be like,
Let's write something together. And you can, you know, I think you have to kind of take it as every pairing experience is different and you're going to do things differently with some people than other people. and try to lean into what those are. I can think back to when Tim Oettinger and I would pair. We would talk a lot.
about what we were doing. And we would even say, I'm writing this method, and this method's going to do this. And what do you think about this? And what if I use a switch statement here? No, I shouldn't use that. Whatever it is. There's other people that I've
where we basically don't talk at all and sometimes that can be great sometimes there's people that you can pair with and you just kind of form some kind of mind meld with them and you're sitting there looking at the same screen and writing stuff and just kind of pointing and grunting. But it works because you're in sync. This isn't always going to be the case. There's also going to be people you're going to pair a program with where it just doesn't work.
And you start to feel like, okay, I'm programming and they're watching. or they're programming and I'm watching them. If you find yourself pair programming and you're in that state where you're watching them or they're watching you and you can just tell this isn't working, what do you do? What advice do you have to resolve that?
There are some games you can play. I would encourage people to try some of those. So you can do things like ping-ponging, where I write the test and you write the production code, and vice versa. And we kind of flip. back and forth and so that forces you to have to include the other person that they have to do it. Would you mid-session just say, like, hey, this isn't working, let's try ping-ponging? What would you do or say?
I usually get pretty active about it. Yeah, I would say something. You try not to be like, oh, this isn't working. But be like, hey, What if we tried doing this? Generally, this is what happens to me. I'm usually on the side of I'm programming and they're watching me and they're just not engaging and maybe they're not engaging because they think that I'm the expert. Or maybe they're not engaging for some other reason. But hopefully it's not because I smell or something like that.
But, you know, I will just kind of like push over the keyboard and be like, hey, why don't you drive for a while? You know, and try to ask, what would you do? Even though I know exactly what kind of code I was about to write.
What kind of code would you write here? What do you think we should do? Try to get that engagement with somebody. Sometimes it doesn't I like digging into this stuff because I agree with what you said, that each pairing session is sort of unique, and each pairing relationship is too. And not all pairs work, but certainly not all pairing experiences are the same. And I think a lot of the challenge that I've heard people run into is they
They try pair programming either because they thought it sounded interesting or somebody sort of encouraged them to do it or force them into it, and they try it, and they have a negative experience. And maybe they notice it's a negative experience during the process. Maybe they don't realize until afterwards. But it turns them off to it. possibly forever and
Sometimes like really entrenches this belief that pairing is bad. And one of the things that I'm trying to do with some of these conversations is surface both the tactics to avoid that so that your pairing experience is positive, but also highlight some of the benefits that the practice has in the first place. so that folks are willing to make the effort to give it a shot. It's not easy, and it can be exhausting. A lot of us that are in software are introverts.
and including myself. And when I'm engaging in pair programming, that's tiring. It's tiring to talk to someone and to interact with someone to that degree all day long. And I see a lot of places that try to do pair programming or try to require pair programming, and they just take it too far. They're like, you're going to be pair programming from 9 o'clock in the morning till 4 o'clock in the afternoon. and that's too long. You need to make sure you have breaks.
You need to make sure you have some alone time. You need to give people the ability to go deal with their emails and their personal things that they might have to deal with throughout the day. And that pair programming time should probably be, you know, It's not an eight-hour thing. You can't program for eight hours and have it be effective. You could probably do it for like six, maybe.
But taking the breaks in between, even if you're, okay, this is a six-hour session, but every 50 minutes we're going to take a 10-minute break or even a five-minute break makes a huge difference. Yes, it makes a huge difference. I think a lot of people just, they do have those negative experiences. The other problem is that we throw people, we say, hey, you guys got to go all per programming.
But we don't explain to them how to do that. Nobody guides them and nobody coaches them on how to actually do it. So now you just have two people looking at a screen. And each of their own. And they don't really know what they're doing or why they're there. And yeah, that can feel, it can feel weird. And it can feel, and we are people who are drawn to a career of writing cryptic words in tiny black boxes that an alien is listening to.
Some people are very extroverted and they're great too, but there's just so many people in our industry that this is kind of foreign to them. And they'll be okay with it, but you've got to get the right angle, and you've got to make it a positive experience, and you've got to make it fun. And if it's painful, and if you're not having a good time, stop doing it and figure out something else. Figure out how to change it up. But don't just sit there and be miserable. for weeks.
Yeah, I think that's good advice. Could you speak a little bit about the teams that you work with and whether or not you're in person with them every day, hybrid, remote, and that sort of thing? John Deere, like a lot of companies would. like people to be in person. But we have a lot of remote people. And honestly, I think in our industry...
that the ship has sailed and we are in a world where things are going to be remote. Especially software developers who have a lot of choice and can work anywhere. then they are going to work anywhere. And there's been people remote in our industry for years and years and years. and it hasn't been a problem. Agile did its big thing, and XP was with pair programming and co-locating teams.
And I'm not going to say that that's not like the ideal state. I think it probably is the ideal state, but it's just not the world we live in. And so you just got to get used to this idea that there's going to be a remote team. And here in the Midwest, there's just not enough. software developers in Des Moines, Iowa.
to necessarily fill all the demand of all the companies that are in Des Moines, Iowa. Someone has to be remote, and we have people in Seattle and San Francisco and Austin and everywhere else, and we have offices in some of those places too, but we We still have those remote people. The tooling for it has gotten better than it used to be. The first experience I had, I think, was over WebEx, and it was pretty brutal.
And those experiences have gotten better. The tooling's gotten better. I've noticed that my little area of John Deere, that the... Even the teams where there's a lot of people that are on site in the same office, they still have a really strong presence online in some kind of group area. And they will have, you know... We use Teams. which i'm not a huge fan of but it can serve it can do it
And Teams having a common online area where, not just for peer programming, just for existence. So that, you know, we always have this online. area with cameras and stuff that people can just hop in and talk to the team the more connected those teams are the stronger they are because they're able to create that trust between the teams. I think that's the important part, is creating that I trust all of these other members on my team.
And I would trust them with any part of the team. I'm not worried if anybody's going to push to production today or... anything like that because, you know, I know that our product is solid and we have good tests and we have the ability that if we do push out something to production and it breaks, we can patch it really, really fast. And that's it. It's all about the confidence. And it's all about trusting your teammates.
And if you can nail that, then you're going to have a good time, regardless of whether we're in the same room or not. Well, it sounds as if you believe it's easier to build that trust, though, if you are a person. I personally feel that... But maybe not. I've had really good, you know, when I was at geo-learning for a lot of that, you know, some of those coaches after that initial training, Most of our coaches were remote, and we were doing remote pair programming.
The technology has certainly come a long way since then, too, which should hopefully make that easier. Going back to something that I mentioned before, is there a particular practice, habit, or ritual that you or any of the teams that you work with regularly have that you're proud of, that you feel like, hey, This is something that we've sort of nailed that really allows us to work effectively together.
Of all the technical practices, I find behavior-driven development to be the most valuable. And if you can produce a really fast behavioral driven development suite. It's magic. And this kind of goes hand in hand in my mind with If I'm going to have a project for my team, I should be able to hand it to somebody, a new developer. That developer should basically be able to say, get clone this repository, verify.
does everything. And it's super fast. And there's not a lot of complex setup. There's nothing that they have to do. And the whole thing runs with all of its test suite really, really fast. And I don't even use The last team that I worked on, some of the core user LAN security stuff within our system, And we have a system that has a handwritten behavior-driven development suite. We don't use Cucumber or anything like that. We just wrote it purely in Java. And the thing...
is so fast and goes through like every permutation that you could think of. And it just gives such amazing confidence. Confidence is really the key. I think I said this before. of if I'm confident that my changes aren't going to break anything, that is the most magical thing you can do for a team. to take away the apprehension that I'm going to break something because that leads to not over-engineering.
you're not going to go out of your way to do a bunch of weird stuff because you think it might. What if there might be a null here? I know there's not going to be a null there. And if you can create this that trust and that confidence in the system that you're doing. And I really feel like BDD is the only way you truly get that full confidence because unit testing and TDD is great and will produce a nice system for you that can be changed.
but it doesn't give you that feeling of how does everything work together, which is an even bigger problem today than it was back then because our systems are so much more distributed today with microservices and integrations and stuff. If you can produce something that can more easily guarantee all of that, then That's the magic bullet. And for folks who aren't familiar with BDD or haven't done it before, can you give a really succinct summary or explanation of what exactly that means?
So BDD stands for Behavior Driven Development. And it's kind of spun off of TDD. But the idea is that you're writing a series of tests that are going to test the behavior of the system as a whole. And what you're trying to do really is create a system of tests that exists just below the URL. So it's not necessarily like hitting React or the UI of an application or whatever it's written in. It's hitting the APIs that go through that.
and you write them in a very business language kind of way. So you say, like, given a user logs in named Larry, when Larry does this, then this other thing happens. And that is hitting the actual full stack of whatever that system under test is. And it might be going all the way to the database, and back. So you're getting a full stick through the system of
We're going to do this and everything works and then it comes back and I can validate it and verify it. You don't want a ton of those kinds of tests. You don't want to go super crazy with them. All of your main user stories should be covered. And when do you use BDD versus TDD? I use them both at the same time. So what I'll start off with is I have a user story. I'll write a BDD test. That test will fail. Then I will go and start TDDing the actual implementation code.
Maybe the BDD, the only thing it really did was establish an interface that did nothing. So then I'll go into TDD and start working out the middle part there and then kind of coming out of that loop and back up to the BDD loop and then kind of finishing that and making sure that all works. So it's loops inside of loops inside of loops. which is all we ever do, isn't it? It's all loops inside of loops.
I know that'll be helpful for folks who maybe have heard these terms before, but have never actually... been in an environment where it was practiced regularly so thank you thank you for that ron i guess my final question would just be like what's what's one thing you hope listeners take away from this from this conversation you know technology is moving really fast there's a lot of things out there
At the end of the day, we're all human beings, and we are so much more advanced than any of the computer systems that we work on. But we're humans, and we work with other humans, building things for humans. and keep the humanity in mind. And keep the humanity in mind with the people you work with and with your customers. That is what I want everybody to concentrate on. That we are all in this together on the same planet. Never go wrong with and compassion and finding other people enjoyable.
but it's such a positive message. to end on Brian so thank you for sharing that with me sharing that with our audience I think that sort of stuff goes a really long way So thank you again for being generous with your time, your insight, with the positive message to leave us with. We'll look forward to chatting again soon. Yeah, talk to you later.
Thanks for joining us on Distributed. If you want to learn more about what we covered in this episode, or if you want to share your own thoughts, follow at Tupel on X or visit distributed.fm.