Iterative Work and Smaller Slices

Joël shares a unique, time-specific bug he encountered, which causes a page to crash only in January. This bug has been fixed in previous years, only to reemerge due to subsequent changes. Stephanie talks about her efforts to bring more structure to her work-from-home environment. She describes how setting up a bird feeder near her desk and keeping chocolates at her desk serve as incentives to work more from her desk.

Together, Stephanie and Joël take a deep dive into the challenges of breaking down software development tasks into smaller, more manageable chunks. They explore the concept of 'vertical slice' development, where features are implemented in thin, fully functional segments, contrasting it with the more traditional 'horizontal slice' approach. This discussion leads to insights on collaborative work, the importance of iterative development, and strategies for efficient and effective software engineering.

• thoughtbot Live Streams
• Stephanie’s Live Stream
• Joël’s Talk on Time
• Finish the Owl Meme
• Full Stack Slices
• Elephant Carpaccio
• Outside-in Feature Development
• Working Iteratively

Transcript:

 STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn.

JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way.

STEPHANIE: So, Joël, what's new in your world in the year 2024?

JOËL: Yeah, it's 2024. New year, new me. Or, in this case, maybe new year, new bugs? I'm working on a project where I ran into a really interesting time-specific bug. This particular page on the site only crashes in the month of January. There's some date logic that has a weird boundary condition there, and if you load that page during the month of January, it will crash, but during the entire rest of the year, it's fine.

STEPHANIE: That's a fun New Year's tradition for this project [laughs], fixing this bug [laughs] every year.

JOËL: It's been interesting because I looked a little bit at the git history of this bug, and it looks like it's been fixed in past Januarys, but then the fix changes the behavior slightly, so people bring the behavior back correct during the rest of the year that also happens to reintroduce the bug in January, and now I'm back to fixing it in January. So, it is a little bit of a tradition.

STEPHANIE: Yeah, that is really funny. I was also recently debugging something, and we were having some flakiness with a test that we wrote. And we were trying to figure out because we had some date/time logic as well. And we were like, is there anything strange about this current time period that we are in that would potentially, you know, lead to a flaky test?

And we were looking at the clock and we're like, "I don't think it's like, you know, midnight UTC or anything [laughs] like that." But, I mean, I don't know. It's like, how could you possibly think of, like, all of the various weird edge cases, you know, related to that kind of thing? I don't think I would ever be like, huh, it's January, so, surely, that must [laughs] mean that that's this particular edge case I'm seeing.

JOËL: It's interesting because I feel like there's a couple of types of time-specific bugs that we see pretty frequently. If you're near the daylight savings boundary, let's say a week before sometimes, or whatever you're...if you're doing, like, a week from now logic or something like that, typically, I'll see failures in the test suite or maybe actual crashes in the code a week before springing forward and a week before falling back. And then, like you said, sometimes you see failures at the end of the day, Eastern time for me, when you approach that midnight UTC time boundary. I think this is the first time I've seen a failure in January due to the month being, like, a month boundary...or it's a year boundary really is what's happening.

STEPHANIE: Yeah. That just sounds like another [laughs] thing you have to look out for. I'm curious: are you going to fix this bug for real or leave it for [laughs] 2025?

JOËL: I've got a fix that I think is for real and that, like, not only fixes the break in January but also during the rest of the year gives the desired behavior. I think part of what's really interesting about this bug is that there are some subtle behavioral changes between a few different use cases where this code is called, part of which depend on when in the year you're calling it and whether you want to see it for today's date versus you can also specify a date that you want to see this report. And so, it turns out that there are a lot more edge cases than might be initially obvious.

So, this turned into effectively a product discussion, and realizing, wait a minute, the code isn't telling the full story. There's more at a product level we need to discuss. And actually, I think I learned a lot about the product there. So, while it was maybe a surprising and kind of humorous bug to come across, I think it was actually a really good experience.

STEPHANIE: Nice. That's awesome. That's a pretty good way to start the year, I would say.

JOËL: I'd say so. How about you? What's new in your world?

STEPHANIE: So, I don't know, I think towards the end of the year, last year, I was in a bit of a slump where I was in that work-from-couch phase of [laughs] the year, you know, like, things are slowing down and I, you know, winter was starting here. I wanted to be cozy, so I'd, you know, set up on the couch with a blanket.

And I realized that I really wasn't sitting at my desk at all, and I kind of wanted to bring a little bit of that structure back into my workday, so I [chuckles] added some incentives for me to sit at my desk, which include I recently got a bird feeder that attaches to the window in my office. So, when I sit at my desk, I can hopefully see some birds hanging out.

They are very flighty, so I've only seen birds when I'm, like, in the other room. And I'm like, oh, like, there's a bird at the bird feeder. Like, let me get up close to, like, get to admire them. And then as soon as I, like [laughs], get up close to the window, they fly away. So, I'm hoping that if I sit at my desk more, I'll spontaneously see more birds, and maybe they'll get used to, like, a presence closer to the window. And then my second incentive is I now have little chocolates at my desk [laughs].

JOËL: Nice.

STEPHANIE: I've just been enjoying, like, a little treat and trying to keep them as a...okay, I've worked at my desk for an hour, and now I get a little reward for that [laughs].

JOËL: I like that. Do you know what kind of species of birds have been coming to your feeder?

STEPHANIE: Ooh, yes. So, we got this birdseed mix called Cardinal and Friends [laughs].

JOËL: I love that.

STEPHANIE: So, I have seen, like, a really beautiful red male cardinal come by. We get some robins and some chickadees, I think. Part of what I'm excited for this winter is to learn more how to identify more bird species. And I usually like to be out in nature and stuff, and winter is a hard time to do that. So, this is kind of my way of [chuckles] bringing that more into my life during the season.

So, this is our first episode after a little bit of a break for the holidays. There actually has been some content of ours that has been published out in the world on the internet [laughs] during this time. And just wanted to point out in the few weeks that there weren't any Bike Shed episodes, I ended up doing a thoughtbot Rails development livestream with thoughtbot CEO Chad Pytel, and that was my first-time live streaming code [laughs].

And it was a really cool experience. I'm glad I had this podcast experience. So, I'm like, okay, well I have, you know, that, like, ability to do stuff kind of off script and present in the moment. But yeah, that was a really cool thing that I got to do, and I feel a little bit more confident about doing those kinds in the future.

JOËL: And for those who are not aware, Chad does–I think it's a weekly live stream on Fridays where he's doing various types of code. So, he's done some work on some internal projects. He did a series where he upgraded, I think, a Rails 2 app all the way to Rails 7, typically with a guest who's another teammate from thoughtbot working on a thing. So, for those of our listeners that might find interesting, we'll put a link in the show notes where you can go see that. I think it's on YouTube and on Twitch.

STEPHANIE: Yes.

JOËL: What did you pair on? What kind of project were you doing for the livestream?

STEPHANIE: So, we were working on thoughtbot's internal application called Hub, which is where we have, like, our internal messaging features. It's where we do a lot of our business operations-y things [laughs]. So, all of the, like, agency work that we do, we use our in-house software for that, and so Chad and I were working on a feature to introduce something that would help out with how we staff team members on projects.

In other content news [laughs], Joël, I think you have something to share as well.

JOËL: Yeah. So, we've mentioned on past episodes that I gave a talk at RubyConf this past November all about what the concept of time actually means within a program and the different ways of representing it, and the fact that time isn't really a single thing but actually kind of multiple related quantities. And over the holiday break, the talks from that conference got published. I'm pretty excited that that is now out there. We'd mentioned that as a highlight in the previous episode, highlighting accomplishments for the year, but it just wasn't quite out yet. We couldn't link it there. So, I'll leave a link in the show notes for this episode for anyone who's interested in seeing that.

STEPHANIE: Sounds like that talk is also timely for a debug you --

JOËL: Ha ha ha!

STEPHANIE: Were also mentioning earlier in the episode. So, a few episodes ago, I believe we mentioned that we had recently had, like, our company internal hackathon type thing where we have two days to get together and work with team members who we might not normally work with and get some cool projects started or do some team bonding, that kind of thing.

And since I'm still, you know, unbooked on client work, I've been doing a lot of internal thoughtbot stuff, like continuing to work on the Hub app I mentioned just a bit ago. And from the hackathon, there was some work that was unfinished by, like, a project team that I decided to pick up this week as part of my internal work.

And as I was kind of trying to gauge how much progress was made and, like, what was left to accomplish to get it over the finish line so it could be shipped, I noticed that because there were a couple of different people working on it, they had broken up this feature which was basically introducing, like, a new report for one of our teams to get some data on how certain projects are going.

And there was, like, a UI portion and then some back-end portion, and then part of the back-end portion also involved a bit of a complex query that was pulled out as a separate ticket on its own. And so, all of those things were slightly, you know, were mostly done but just needed those, like, finishing touches, and then it also needed to come together.

And I ended up pairing on this with another thoughtboter, and we spent the same amount of time that the hackathon was, so two days. We spent those two days on that, like, aspect of putting it all together. And I think I was a bit surprised by how much work that was, you know, we had kind of assumed that like, oh, like, all these pieces are mostly finished, but then the bulk of what we spended our time doing was integrating the components together.

JOËL: Does this feel like a bit of a finish the rest of the OWL meme?

STEPHANIE: What is that meme? I'm not familiar with it, but now I really want to know [laughs].

JOËL: It's a meme kind of making fun of some of these drawing tutorials where they're like, oh; first you draw, like, three circles.

STEPHANIE: [laughs]

JOËL: And then just finish the rest of the owl.

STEPHANIE: [laughs]

JOËL: And I was thinking of this beautifully drawn picture.

STEPHANIE: Oh, that's so funny. Okay, yeah, I can see it in my head [laughs] now. It's like how to go from three circles, you know, to a recognizable [laughs] owl animal.

JOËL: So, especially, they're like, oh, you know, like, we put in all the core classes and everything. It's all just basically there. You just need to connect it all together, and it's basically done [laughs]. And then you spend a lot of time actually getting that what feels like maybe the last 20 or 10% but takes maybe 80% of the time.

STEPHANIE: Yeah, that sounds about right. So, you know, kind of working on that got me thinking about the alternative, which is honestly something that I'm still working on getting better at doing in my day-to-day. But there is this idea of a vertical slice or a full-stack slice, and that, basically, involves splitting a large feature into those full-stack slices. So, you have, like, a fully implemented piece rather than breaking them apart by layers of the stack.

So, you know, I just see pretty frequently that, like, maybe you'll have a back-end ticket to do the database migration, to create your models, just whatever, maybe your controllers, or maybe that is even, like, another piece and then, like, the UI component. And those are worked on separately, maybe even by different people. But this vertical slice theory talks about how what you really want is to have a very thin piece of the feature that still delivers value but fully works.

JOËL: As opposed to what you might call a horizontal slice, which would be something like, oh, I've built three Rails models. They're there. They're in the code. They talk to tables in the database, but there's nothing else happening with them. So, you've done work, but it's also more or less dead code.

STEPHANIE: Yeah, that's a good point. I have definitely seen a lot of unused code paths [laughs] when you kind of go about it that way and maybe, like, that UI ticket never gets completed.

JOËL: What are some tips for trying to do some of these narrower slices? Like, I have a ticket, and I have some work I need to do. And I want to break it down because I know it's going to be too big, and maybe the, like, intuitive way to do it is to split it by layers of your stack where I might do all the models, commit, ship that, deploy, then do some controllers, then do some view, or something like that, and you're suggesting instead going full stack. How do you break down the ticket more when all the pieces are interrelated?

STEPHANIE: Yeah, that's a great point. One easy way to visualize it, especially if you have designs or something for this feature, right? Oftentimes, you can start to parse out sections or components of the user interface to be shipped separately. Like, yes, you would want all of it to have that rich feature, but if it's a view of some cards or something, and then, yeah, there's, like, the you can filter by them. You can search by them. All of those bits can be broken up to be like, well, like, the very basic thing that a customer would want to see is just that list of cards, and you can start there.

JOËL: So, aggressively breaking down the card at, like, almost a product level. Instead of breaking it down by technical pieces, say, like, can we get even smaller amounts of behavior while still delivering value?

STEPHANIE: Yeah, yeah, exactly. I like that you said product level because I think another axis of that could also be complexity. So, oftentimes, you know, I'll get a feature, and we're like, oh, we want to support these X number of things that we've identified [laughs]. You know, if it's like an e-com app you're building, you know, you're like, "Do we have all these products that we want to make sure to support?" And, you know, one way to break that down into that vertical slice is to ask, like, what if we started with just supporting one before we add variants or something like that?

Teasing out, like, what would end up being the added complexity as you're developing, once you have to start considering multiple parameters, I think that is a good way to be able to start working more iteratively. And so, you don't have to hold all of that complexity in your head.

JOËL: It's almost a bit of like a YAGNI principle but applied to features rather than to code.

STEPHANIE: Yeah. Yeah. I like that. At first, I hesitated a little bit because I've certainly been in the position where someone has said like, "Well, we do really need this [laughs]."

JOËL: Uh-huh. And, sometimes, the answer is, yes, we do need that, but what if I gave you a smaller version of that today, and we can do the other thing tomorrow?

STEPHANIE: Right. Yeah, it's not like you're rejecting the idea that it's necessary but the way that you get about to that end result, right?

JOËL: So, you keep using the term vertical slice or full-stack slice. I think when I hear that term, I think of specifically an article written by former thoughtboter, German Velasco, on our blog. But I don't know if that's maybe a term that has broader use in the industry. Is that a term that you've heard elsewhere?

STEPHANIE: That's a good question. I think I mostly hear, you know, some form of like, "Can we break this ticket down further?" and not necessarily, like, if you think about how, right? I'm, like, kind of doing a motion with my hand [chuckles] of, like, slicing from top to bottom as opposed to, you know, horizontal.

Yeah, I think that it may not be as common as I wish it were. Even if there's still some amount of adapting or, like, persuading your team members to get on board with this idea, like, I would be interested in, like, introducing that concept or that vocabulary to get teams talking about, like, how do they break down tickets? You know, like, what are they considering? Like, what alternatives are there? Like, are horizontal slices working for them or not?

JOËL: A term that I've heard floating around and I haven't really pinned down is Elephant Carpaccio. Have you heard that before?

STEPHANIE: I have, only because I, like, discovered a, like, workshop facilitation guide to run an exercise that is basically, like, helping people learn how to identify, like, smaller and smaller full-stack slices. But with the Elephant Carpaccio analogy, it's kind of like you're imagining a feature as big as an elephant. And you can create, like, a really thin slice out of them, and you can have infinite number of slices, but they still end up creating this elephant. And I guess you still get the value of [chuckles] a little carpaccio, a delicious [laughs] appetizer of thinly sliced meat.

JOËL: I love a colorful metaphor. So, I'm curious: in your own practice, do you have any sort of guidelines or even heuristics that you like to use to help work in a more, I guess, iterative fashion by working with these smaller slices?

STEPHANIE: Yeah, one thought that I had about it is that it plays really well with Outside-In Test Driven Development.

JOËL: Hmmm.

STEPHANIE: Yeah. So, if, you know, you are starting with a feature test, you have to start somewhere and, you know, maybe starting with, like, the most valuable piece of the feature, right? And you are starting at that level of user interaction if you're using Capybara, for example. And then it kind of forces you to drop down deeper into those layers.

But once you go through that whole process of outside-in and then you arrive back to the top, you've created your full-stack feature [laughs], and that is shippable or, like, committable and, you know, potentially even shippable in and of itself. And you already have full test coverage with it. And that was a cool way that I saw some of those two concepts work well together.

JOËL: Yeah, there is something really fun about the sort of Red-Green-Refactor cycle that TDD forces on you and that you're typically writing the minimum code required to pass a test. And it really forces you out of that developer brain where you're just like, oh, I've got to cover my edge cases. I've got to engineer for some things. And then maybe you realize you've written code that wasn't necessary. And so, I've found that often when I do, like, actually TDD a feature, I end up with code that's a lot leaner than I would otherwise.

STEPHANIE: Yes, lean like a thin slice of Elephant Carpaccio.

[laughter]

JOËL: One thing you did mention that I wanted to highlight was the fact that when you do this outside-in approach for your tiny slice, at the end, it is shippable. And I think that is a core sort of tenet of this idea is that even though you're breaking things down into smaller and smaller slices, every slice is shippable to production. Like, it doesn't break the build. It doesn't break the website. And it provides some kind of value to the user.

STEPHANIE: Yeah, absolutely. I think one thing that I still kind of get hung up on sometimes, and I'm trying to, you know, revisit this assumption is that idea of, like, is this too small? Like, is this valuable enough? When I mentioned earlier that I was working on a report, I think there was a part of me that's like, could I just ship a report with two columns [laughs]? And the answer is yes, right? Like, I thought about it, and I was like, well, if that data is, like, not available anywhere else, then, yeah, like, that would be valuable to just get out there.

But I think the idea that, like, you know, originally, the hope was to have all of these things, these pieces of information, you know, available through this report, I think that, like, held me back a little bit from wanting to break it down. And I held it a little bit too closely and to be like, well, I really want to, like, you know, deliver something impressive. When you click on it, it's like, wow, like, look at all this data [laughs]. So, I'm trying to push back a little bit on my own preconceived notions that, like, there is such a thing as, like, a too small of a demo.

JOËL: I've often worked with this at a commit level, trying to see, like, how small can I get a commit, and what is too small? And now you get into sort of the fraught question of what is a, you know, atomic commit? And I think, for me, where I've sort of come down is that a commit must pass CI. Like, I don't want a commit that's going to go into the main branch. I'm totally pro-work-in-progress commits on a branch; that's fine. But if it's going to get shipped into the main branch, it needs to be green. And it also cannot introduce dead code.

STEPHANIE: Ooh.

JOËL: So, if you're getting to the point where you're breaking either of those, you've got some sort of, like, partial commit that's maybe too small that needs more to be functional. Or you maybe need to restructure to say, look, instead of adding just ten models, can I add one model but also a little bit of a controller and a view? And now I've got a vertical slice.

STEPHANIE: Yeah, which might even be less code [laughs] in the end.

JOËL: Yes, it might be less code.

STEPHANIE: I really like that heuristic of not introducing dead code, that being a goal. I'm going to think about that a lot [laughs] and try to start introducing that into when I think something is ready.

JOËL: Another thing that I'll often do, I guess, that's almost like it doesn't quite fit in the slice metaphor, but it's trying to separate out any kind of refactor work into its own commit that is, you know, still follows those rules: it does not introduce dead code; it does not break the build; it's independently shippable. But that might be something that I do that sets me up for success when I want to do that next slice.

So, maybe I'm trying to add a new feature, but just the way we built some of the internal models, they don't have the interface that I need right now, and that's fine because I don't want to build these models in anticipation of the future. I can change them in the future if I need. But now the future has come, and I need a slightly different shape. So, I start by refactoring, commit, maybe even ship that deploy. Maybe I then do my small feature afterwards. Maybe I come back next week and do the small feature, but there are two independent things, two different commits, maybe two different deploys.

I don't know that I would call that refactor a slice and that it maybe goes across the full stack; maybe it doesn't. It doesn't show to the user because a refactor, by definition, is just changing the implementation without changing behavior. But I do like to break that out and keep it separate. And I guess it helps keep my slices lean, but I'm not quite sure where refactors fit into this metaphor.

STEPHANIE: Yeah, that's interesting because, in my head, as I was listening to you talk about that, I was visualizing the owl again, the [laughs] owl meme. And I'm imagining, like, the refactoring making the slice richer, right? It's like you're adding details, and you're...it's like when you end up with the full animal, or the owl, the elephant, whatever, it's not just, like, a shoddy-looking drawing [laughs]. Like, ideally, you know, it has those details. Maybe it has some feathers. It's shaded in, and it is very fleshed out. That's just my weird, little brain trying [laughs] to stretch this metaphor to make it work.

Another thing that I want to kind of touch a little bit more about when we're talking about how a lot of the work I was spending recently was that glue work, you know, the putting the pieces together, I think there was some aspect of discovery involved that was missed the first time around when these tickets were broken up more horizontally. I think that one really important piece that I was doing was trying to reconcile the different mental models that each person had when they were working on their separate piece.

And so, maybe there's, like, an API, and then the frontend is expecting some sort of data, and, you know, you communicate it in a way that's, like, kind of hand-off-esque. And then when you put it together, it turns out that, oh, the pieces don't quite fit together, and how do you actually decide, like, what that mental model should be? Naming, especially, too, I've, you know, seen so many times when the name...like, an attribute on the frontend is named a little bit different than whatever is on the backend, and it takes a lot of work to unify that, like, to make that decision about, should they be the same? Should they be different? A lot of thought goes into putting those pieces together.

And I think the benefit of a full-stack slice is that that work doesn't get lost. Especially if you are doing stuff like estimating, you're kind of discovering that earlier on. And I think what I just talked about, honestly, is what prevents those features from getting shipped in the end if you were working in a more horizontal way.

JOËL: Yeah. It's so easy to have, like, big chunks of work in progress forever and never actually shipping. And one of the benefits of these narrower slices is that you're shipping more frequently. And that's, you know, interesting from a coding perspective, but it's kind of an agile methodology thing as well, the, like, ship smaller chunks more frequently. Even though you're maybe taking a little bit more overhead because you're having to, like, take the time to break down tasks, it will make your project move faster as a whole.

An aspect that's really interesting to me, though, is what you highlighted about collaboration and the fact that every teammate has a slightly different mental model. And I think if you take the full-stack slice and every member is able to use their mental model, and then close the loop and actually, like, do a complete thing and ship it, I think it allows every other member who's going to have a slightly different mental model of the problem to kind of, yes, and... the other person rather than all sort of independently doing their things and having to reconcile them at the end.

STEPHANIE: Yeah, I agree. I think I find, you know, a lot of work broken out into backend and frontend frequently because team members might have different specialties or different preferences about where they would like to be working. But that could also be, like, a really awesome opportunity for pairing [laughs]. Like, if you have someone who's more comfortable in the backend or someone more comfortable in the frontend to work on that full-stack piece together, like, even outside of the in-the-weeds coding aspects of it, it's like you're, at the very least, making sure that those two folks have that same mental model.

Or I like what you said about yes, and... because it gets further refined when you have people who are maybe more familiar with, like, something about the app, and they're like, "Oh, like, don't forget about we should consider this." I think that, like, diversity of experience, too, ends up being really valuable in getting that abstraction to be more accurate so that it best represents what you're trying to build.

JOËL: Early on, when I was pretty new working at thoughtbot, somebody else at the company had given me the advice that if I wanted to be more effective and work faster on projects, I needed to start breaking my work down into smaller chunks, and this is, you know, fairly junior developer at the time. The advice sounds solid, and everything we've talked about today sounds really solid. Doing it in practice is hard, and it's taken me, you know, a decade, and I'm still working on getting better at it.

And I wrote an article about working iteratively that covers a lot of different elements where I've kind of pulled on threads and found out ways where you can get better at this. But I do want to acknowledge that this is not something that's easy and that just like the code that we're working on iteratively, our technique for breaking things down is something that we improve on iteratively. And it's a journey we're all on together.

STEPHANIE: I'm really glad that you brought up how hard it is because as I was thinking about this topic, I was considering barriers into working in that vertical slice way, and barriers that I personally experience, as well as just I have seen on other teams. I had alluded to some earlier about, like, the perception of if I ship this small thing, is it impressive enough, or is it valuable enough? And I think I realized that, like, I was getting caught up in, like, the perception part, right? And maybe it doesn't matter [chuckles], and I just need to kind of shift the way I'm thinking about it.

And then, there are more real barriers or, like, concrete barriers that are tough. Long feedback loops is one that I've encountered on a team where it's just really hard to ship frequently because PR reviews aren't happening fast enough or your CI or deployment process is just so long that you're like, I want to stuff everything into [chuckles] this one PR so that at least I won't have to sit and wait [laughs].

And that can be really hard to work against, but it could also be a really interesting signal about whether your processes are working for you. It could be an opportunity to be like, "I would like to work this way, but here are the things that are preventing me from really embracing it. And is there any improvement I can make in those areas?"

JOËL: Yeah. There's a bit of a, like, vicious cycle that happens there sometimes, especially around PR review, where when it takes a long time to get reviews, you tend to decide, well, I'm going to not make a bunch of PRs; I'm going to make one big one. But then big PRs are very, like, time intensive and require you to commit a lot of, like, focus and energy to them, which means that when you ask me for a review, I'm going to wait longer before I review it, which is going to incentivize you to build bigger PRs, which is going to incentivize me to wait longer, and now we just...it's a vicious cycle.

So, I know I've definitely been on projects where a question the team has had is, "How can we improve our process? We want faster code review." And there's some aspect of that that's like, look, everybody just needs to be more disciplined or more alert and try to review things more frequently. But there's also an element of if you do make things smaller, you make it much easier for people to review your code in between other things.

STEPHANIE: Yeah, I really liked you mentioning incentives because I think that could be a really good place to start if you or your team are interested in making a change like this, you know, making an effort to look at your team processes and being like, what is incentivized here, and what does our system encourage or discourage? And if you want to be making that shift, like, that could be a good place to start in identifying places for improvement.

JOËL: And that happens on a broader system level as well. If you look at what does it take to go from a problem that is going to turn into a ticket to in-production in front of a client, how long is that loop? How complex are the steps to get there? The longer that loop is, the slower you're iterating. And the easier it is for things to just get hung up or for you to waste time, the harder it is for you to change course.

And so, oftentimes, I've come on to projects with clients and sort of seen something like that, and sort of seen other pain points that the team has and sort of found that one of the root causes is saying, "Look, we need to tighten that feedback loop, and that's going to improve all these other things that are kind of constellation around it."

STEPHANIE: Agreed. On that note, shall we wrap up?

JOËL: Let's wrap up.

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

JOËL: This show has been produced and edited by Mandy Moore.

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

ALL: Byeeeeeeee!!!!!!!

AD:

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed