Hello, engineering leaders. Welcome to the Kyle Rowland Podcast. This is your hub for diving deep into the intricacies of software engineering, leadership, and advanced techniques. From tackling the industry's biggest challenges to answering the questions that keep you up at night, we're here to elevate your leadership journey. Whether you're leading a team or an entire department, let's navigate the tech world together and inspire greatness.
Well, hello, everyone. Welcome to the Kyle Rowland podcast. My name is Kyle Rowland. Today, we're going to have some really practical advice for you as an engineering leader. So one of the challenges that we have as we get into leading engineering teams is to really understand how to lead them. Well, one of the challenges there is what can we measure? What kind of things can we look at to make sure that we're really going after what matters? So what we're going to be talking about today is...
TBD, trunk-based development. Now, this seems like a really technical topic, and it is in a lot of ways, but the key here is specifically for us as engineering leaders. This is a metric. in essence, that we can use to really understand the health of our software development organization and how we're doing in delivering software.
It's kind of hard to see how that might be at first. It's not intuitively obvious, but we're going to jump into that and talk about why that is. So that's why today's episode is called The Ultimate Proxy for Engineering Health. So before we get into all of that, we really need to think squarely about... What does it actually mean to be a great software development organization? How do we know we're being successful? And we've covered this several times in the podcast in the past.
And the real answer to that is the successful software development organization is really putting a lot of value, a lot of usefulness into the hands of its customers. uh for the least amount of outlay so it's typical uh business stuff return on investment But return for a software organization can get a little fuzzy, a little hard to keep your eye on. But it's really that return is how much useful functionality.
How much usefulness are we putting into our customers' hands? So we're going to have to lay a little bit of groundwork as we get into this. The first thing that we're going to talk about is CICD. So the way that CICD and TBD connect, so that's continuous integration and continuous delivery, which is a term that I almost use without defining it because it's gotten so common in the industry over the last 15 years.
and TBD, which is trunk-based development. I'm going to use those shortened versions so I don't talk quite as much as we go forward here. But there's a real connection between these two things. CICD, as the name implies, is the idea that we're always continuously, as the term says, deployed.
integrating our code and deploying it into production for people to use now for that to actually happen some other things need to be in place and what cicd has come to mean as we we talk about jenkins or built servers or or you know automation around the delivery or even um some of the tech that goes along with it like contenderization and this kind of thing and so when we when we talk about are we doing cicd another
Another term that gets wrapped up in is DevOps. When we talk about are we doing these things, it boils down to a lot of times, do we have some of these technical pieces in place? Again, like the build server or build scripting or automated deployments or that kind of thing. And while they're important, it's more important to recognize the principle that we're getting after.
It's astutely named CICD, Continuous Integration and Continuous Deployment. We need to be constantly integrating and constantly deploying without any roadblocks. When we do that, what happens is we get that increased amount of value, increased amount of usefulness going out to our customer. Now, there's two reasons for this, and we've talked about those before, and I'll get into them quickly, is that when we're more continuously doing these things, we're creating more experiments.
a closer and closer match to what the user actually needs or is actually useful to them and furthermore we're just putting stuff in front of them more rapidly so um the something that we sell to somebody today uh is worth more than something that we sell to someone and deliver a week from now so because of both of those facts that we can do more experiments and we're just getting the that value of time in
The more continuous we are, both in integrating our code and deploying it, the better we'll be in both of those spaces. It turns out that CICD is actually really difficult to do in principle, which is why a lot of companies out there will put a Jenkins server up. Well, maybe I'm dating myself. They'll put a... you know they'll get their github actions or whatever the latest automation is around delivery automation and they'll call themselves good and say that they're doing ci cd
Now they may at the same time be doing synchronous pull requests and stopping people's flow in order to do any number of other quality checks or what have you. So they might have the technical pieces in place, but not actually be providing the continuous integration and continuous delivery as a part of their development workflow.
So when we first look at this, certainly back when, and again, anybody who talks about CICD has to give credit to Jess Humble and Mr. Farley for the book that they wrote on this topic. But anybody for the last 15 years since that book has been, I think it's 15 years since that book has been written, really understands the importance at least of giving lip service to this idea. And so a lot of times we put up, again, we put up the server.
The automation server, we call it a day and say we've got CICD. And as we're looking at that, and as we look back on it, when things first started, when we first started talking about CICD in the industry, one of the arguments that came up and one of the things, the objections, was the idea that, oh, we're just talking about going back to cowboy coding, where we just develop something.
code it even on the production server and call it a day when you know as soon as we're done typing the code in and then hoping nothing breaks and it's important to to say that CICD is not that. And so when we, this is where the real crux of the thing is, is that in order to get the ostensible sort of quickness and continuousness that we got from cowboy coding without the cowboy part, there are about 50 different things that need to be in place and need to be done well in order to accomplish it.
And TBD fits right along inside of this. So TBD is basically the idea of working without branches. So one of the popular ways of handling things. In fact, it's probably almost eaten the world. in the same way that Git did is the idea of Git flow and having development branches and feature branches and all of these different complex things that come together and get merged at different times in this kind of thing.
And TBD says, no, we should, everybody who's working on a project should commit to the same branch because only then are we... integrating continuously and not only should we be using that same whether you call it main master trunk or whatever other version control system the main branching the project should be the spot where everybody is is developing to and tbd and the reason they're connected is because if you're not doing tbd you're not really continuously integrating
And because you're not continuously integrating, you're not able to continuously deploy or deliver. And so looking at this. This is what makes TBD such a great metric for determining the overall health of your software development organization, is because in order to TBD... Again, a number of different things have to be in place that are also basically the fundamental pieces that make a fast software development organization.
TBD itself is valuable and unavoidable if you want to maximize your delivery throughput, but the things that it requires in order to make it possible also equally and more or less equally. provide speed and throughput advantages to your engineering practice so one one quick thing to look at with software engineering that that makes this
appealing, if it's not already patently obvious, is that leading by measuring is kind of a bad idea. So we've gotten, there's a lot of, you know, content about leadership and management, about how measurement is important. And undoubtedly it is. And undoubtedly what happens is leadership and management get kind of conflated. And it's important to separate those two things out because... Management largely isn't applicable in the software development space, not in a classic perspective.
So, to disambiguate these two things, I really love John Maxwell's illustration. He says that management is basically cutting your way through a forest or a jungle. helping the folks around you to do it, making sure you're cutting down enough trees per hour, you know, see all of these things that can kind of be measured. And whereas leadership is...
climbing up the ladder and finding out if you're actually in the right jungle. It's corny, it's cute, but it's also right on. And so when we think about that, Leadership is really a creative activity. It's an activity where you're creating a... perspective about where you want to head you're impact you're empowering people to head there and then the management aspect of that is okay
are we executing day to day on that? And so when we're talking about software development, software engineering, and how leadership applies to that, one of the problems is that, again, management doesn't... really apply because all the way down to the line of code we're inventing we're creating and so every every character we type into our ide
all the way up to every choice we make about architecture it's all connected and it all varies based on every decision we make as we go along which means that for at every point along the chain we need to have somebody actively looking to see if we're in the right jungle. And that's the space that the organizational quote-unquote manager fits more readily into.
Even up to the CEO of a good technical organization, if they're really spending their effort dialing in dials about how to maximize things and stuff. It really betrays and disconnects from the activity of software engineering. So all of that to say, when we're talking about... leading in software engineering, and we really mean leading, measuring is almost entirely inappropriate.
So there's a lot of metrics that are positive or that pass along out there in the industry. There's velocity, there's code coverage, there's... you know, times around how quickly we're fixing bugs and these kind of things. All of those are deeply, deeply flawed in terms of telling you about the actual health of your software engineering.
We can make separate podcasts probably on each of those metrics to dive into them and explain why that is. I'm sure if you've worked in the industry for any period of time, you probably have seen them and you've probably seen them. in their deep flawed uselessness. And so this is the appeal of TBD. Now, one caveat, because measurement is so useless,
It is incumbent upon the software engineering leader to be a master of software engineering. So this TBD doesn't, using that as a metric doesn't get you out of that because really to be skilled with that. To be skilled at leading an engineering team, you still have to have a good strength in understanding how all the different pieces of engineering fit together, how you can manipulate them into your context and all of that.
if you want a one-stop glance at how your engineering is in terms of health TBD is phenomenal for that. And again, it's phenomenal for that because all of the things that TBD requires are basically all the things that make up a healthy software organization. So, with that little caveat in mind, I'll jump into just explaining really briefly what some of those are. So, the first and most important one, well...
yeah, it's probably the most important one, is that TBD enforces small feature-focused teams. So if you don't have a small team, the... the communication that's necessary to make sure that, say I'm developer one and you're developer two, I make a change and it affects some of your code.
If we're a small team, we can easily readily, A, from a relationships perspective, we can readily talk through it. We can work out any differences. We can merge any conflicts with zero resistance. I mean, almost none. As that team grows in size, the relationship quality drops, so I'm more likely to get offended by, or you're more likely to get offended by the change that I made. The conversations become more difficult because, again, the relationship quality is lower.
And the familiarity with the code base is going to be different. So we're more likely to be specialized. So if I come into some of your code, you know, I may not be at all familiar.
with it because i've only worked with it once in a blue moon whereas if we're on a nice tight small team i will you know we'll all be regularly working in all the same code and so the confusion will be much less and again just to restate it the relationship quality will be higher so any interpersonal things will be more readily dealt with
And again, the other piece of that was small feature-oriented teams. So as soon as we get away from feature-oriented teams, the alternative to that is the technology-oriented teams. You know, one way to decompose things other than by feature is by technical capability. So, you know, database or API layer or front end layer.
as soon as we start decomposing our teams in that way, we immediately make ourselves discontinuous. So if I have a feature I'm delivering and I'm on the quote-unquote front-end team... And I need to deliver that feature and it needs a piece of information from the database. I've got two other teams. We've sliced it down the typical three layers. I've got two other teams I have to deal with in order to deliver that feature.
I now block on an outside queue that I have no idea what the state is. We go back again to the team size. The team size, the actual practical team size is huge. And not only that.
um there's you know organizational cueing and uh process and all that that gets in the way of whatever conversation needed to happen which makes this real discontinuous so in order to get to real tbd to real cicd small small feature oriented teams are absolutely unavoidable and again small feature oriented teams are what makes an organization really fast in terms of software delivery. Tightly connected to that through the often cited and
rightly so, Conway's law, is small decoupled systems. So again, if our team is larger, our system begins to get large because of that large team. the code base becomes unwieldy for a single developer. So I've got far more code to deal with if I have a large coupled system. And so because there's more code, there's less familiarity, there's less...
likelihood I'm going to get it right. There's a lot more people interested in what my change is, which means that there might be a lot more likelihood or there is a higher probability that there. will be political hurdles to jump in order to make a given change, which really brings some discontinuity to the situation.
And then finally, and this isn't really one element, it's more like four or five, but there are four technical arenas that have to be nailed to really get TBD and really get real CICD. starting from the most obvious is the automated builds. So whether it's a cron job with a shell script or some software as a service online.
uh thing that does it for you you need to automate your builds your testing everything that happens from you know integrating all the way to production there can't be any synchronous code reviews So synchronous code reviews are a massive drain on the continuity of the delivery. Because for a given developer who's gone to push their code, they're immediately...
They're immediately frozen. They have to switch context, all of that. So that's a big problem. Plus, it's obviously on a separate branch in order to do your merge request. So technically, it's clear that you're not going on to... onto the trunk immediately. And furthermore, you're obviously not integrating continuously because you have to stop based on a human meeting of the minds. The next one is feature flags.
So in order to continuously integrate, in order to build on trunk, you need to be able to push code that's not ready to actually be viewed by anyone in production.
by anybody you know by an actual user so you need to be able to be in the middle of building one thing while you're deploying another and the only way to do that is reliably and well is feature flags now this doesn't have to be a fancy feature flag system you can build it yourself it's really not a complicated thing to do but that has to be there in order to keep everybody in trunk and in order to really integrate continuously and then finally
As we can start to see from this, if everybody's putting their code onto the same branch, obviously we need a great... a really strong suite of tests that really ensures that we're not tripping across anybody else's code, breaking anybody's stuff as we're building our own. And so a great suite of tests, the only way to get that is TDD. There's always the argument, oh, but we can do it after the fact. No, you can't. Nobody does testing after the fact to the level that it's necessary.
to make this really possible. And so that makes TDD another piece that's absolutely unavoidable if you want to be doing TBD and ultimately actual CICD. And again, getting us to the goal of delivering software as fast as possible. For every single one of these pieces, you will be delivering under your personal... the capability that you actually have, you'll be delivering slower than that if these pieces aren't both in place and skillfully executed.
So just to restate that, TBD is a great metric for checking out what the actual health of your organization is. Another name for me for TBD is actual CICD because CICD has been sort of distorted to mean, you know, a build server and some build scripts.
Again, it's challenging to use metrics in software engineering at all, and this is one that really provides some excellent value and gives you a good indicator of where you're at. And not only that, if you tug at it and find out why aren't we good at this, it offers some... quickly, very practical ways to improve your organization. And bringing this all back to the ultimate goal is we want to put the most value in the hands of our customers.
And the only way to do that is to deliver as fast as possible. And the only way to do that, to deliver as fast as possible, is with TBD and the other supporting elements that actually... are necessary to realize tbd and again each of these supporting ones directly supports speed and thus value themselves and those were just to recap small teams oriented on value, small decoupled systems, the technical skills of automated builds, no synchronous code reviews, feature flags and TDD.
And when you have all these in place, you're going to be building as fast as possible. You're really going to be making a difference in your industry. And you're really going to be realizing the promise of software on a computer. So with all that, it's been good having you here. Thank you for joining me on the Kyle Roland podcast. I'll see you again next time. You've been listening to the Kyle Roland podcast. We look forward to seeing you again next time.