How You Can Master Vertical Slices Like The Best Developers

in this video I'm going to talk a little bit more in detail about vertical slices and software development and how you can actually apply them in practice within your software development team so to quickly recap on the previous video that I made about this vertical slices are a software development process less about an architecture and if we contrast that with an architecture like a layered architecture where we have things in horizontal layers like a database layer and then business logic and then a presentation layer vertical slices are essentially ways that we think about developing features that cut vertically through these horizontal layers that we would have in our architecture and if you haven't watched the previous video I'll link it right above so that you can go see that and then come back to this video after you watch that so in this video I wanted to talk about how you can practically go approach vertical slices and I wanted to start off with things like user stories and user stories and software development it's more common when you're talking about like agile software development there's a lot of different software development methodologies but with a user story it's kind of like from the perspective of a user and you're talking about the feature and the functionality that they want to have if you're taking this lens um and actually queuing up the work that you want to do within a team and thinking about it from a user story perspective this can align really well with kind of how you would approach a vertical slice and there's a lot that goes into what makes a good user story so I'll touch on a couple of these things but this is certainly like a a deeper conversation with a lot of different opinions so there's lots of resources online for this kind of stuff but I would say that ultimately and this is kind of my perspective on a lot of things finding what works for you and your team is going to be the best way right so you can go listening to all the gurus about everything and they'll tell you the best way but I will kind of tell all of you that the best way is what works for you and your team and that best way might not always apply so always coming back to continuously improve I think is the best way and it's just going to look different over time so when it comes to making good user stories there's this concept of the invest principle it's an acronym and it touches on a few different characteristics of what makes a good user story so the i in the invest principle is for independent so trying to find ways that you can create user stories such that they don't have dependencies on other user stories and this is actually really difficult because a lot of the time as software Engineers when we're thinking about how we go build things we're often thinking about the first part we have to build followed by the second part but again when we're thinking about vertical slices this is a lot more from the approach of functionality for the user so having this lens in mind is definitely sort of difficult for a lot of Engineers and it's a departure from our traditional way of thinking about how we go Implement code but trying to think about feature development this way can really help in terms of isolating the work you want to deliver the n in the invest principle is for negotiable so what's really important here is that the negotiable part is about the description of the user story talks about what's uh you know functionally required but the actual implementation details are not necessarily specified in the user story and this is because if you were to try and prescribe all of the technical details up front when creating a user story you're actually going to kind of be in like almost like a waterfall scenario right so it's almost at odds with that a lot of the time when you're trying to go Implement solutions for user stories there's going to be things along the way that you discover that might not have worked and if you were very prescriptive about the implementation upfront you might find that you get blocked and you say hey this user story just won't work but the reality is the user story and delivering of the functionality probably does work but the implementation you pick just might have to be different so you want to make sure these are negotiable the v in the invest principle is valuable so I'll kind of gloss over this one but you want to make sure that it's valuable functionality for the end user the E and the invest principle is actually for estimable and yes apparently that's a word so uh the concept here is just that your team is able to kind of think about the estimate and the scope of the size of this functionality now this in and of itself is just a huge topic when it comes to software estimations so I think when I read this um and I'm thinking about the value of like of the E uh part of this acronym here I'm I feel that it's mostly just about that the team has an understanding about the scope I don't want to get into details on forecast Ing and accuracy and all of that but I think the fundamental value comes about understanding really what's involved at a high level and not so much like how many hours exactly it's going to take or what T-shirt size it is or how many story points the s in the invest principle is for small so I'll touch on this in just a moment but you're going to want to try to make your user stories small enough that you can go deliver incremental change and of incremental value going to your users when user stories are very large there's a long time between the ability to actually deliver value to a customer and you miss out on a lot of opportunities when that cycle time becomes too great and you're not getting the feedback from customers as you're giving them value and then the T in the invest principle is for testable and I talk about this a ton in all of my videos and blog articles and social media posts but I love code that is testable I think that you can design software upfront to be testable as much as possible and then you're in a position to implement the tests as you need so you can have the confidence in the feature you're delivering so that's going to wrap up the invest principle that acronym and again the idea is just that the invest principle helps kind of Define what a good user story is because a good user story is going to be aligned with having good vertical slices now the one part of all of that that I really wanted to focus on was just this idea of small now if you haven't encountered this yet in your software development Journey it's very common that when you're faced with implementing features sometimes the scope of a feature feels so large that you're not not sure how you could possibly make it small and as much as I like vertical slices I do try to be pragmatic about everything in software engineering so I've definitely encountered situations where a team is focusing so much on trying to break down a complex feature that so much time is spent that in actuality we could have been making good Headway on just starting to implement things and not necessarily having to spend so much time on the perfect way to you know split it into more vertical slices and deliver value there's always going to be trade-offs with the decisions we make and again I like vertical slices a lot but if it's not a good fit you're having a lot of difficulty trying to break things down that's okay I think you can try to look at different ways to actually go implement the deliverable but I think you should try to reflect on why it was difficult to break down and then use a retrospective to kind of look back at this and you know work with the team to say why did we have a hard time trying to break that down into a vertical slice is there something about our Arc texure we don't understand well could we have done a better job kind of defining that user story or maybe understanding that it was truly multiple user stories so I would say don't let it gate you you know if you're spending too much time trying to break things down into smaller pieces but you do want to have a retro process where you can go back and look at this and try to improve for next time I think one of the other benefits of having smaller pieces when we're having deliverables aside from the ability just to have a quicker turnaround time and get feedback on the piece pieces we're giving to customers I think we get a lot of value in the sense that when we're thinking about the implementation of this and the different layers that we might have to cut through with our vertical slice it can actually give us some laser focus on the areas that we have to go touch right so when we have a really broad user story and we're trying to think about a vertical slice for it as we're cross cutting through the layers when it's too broad even at the top level we're going to have a lot of ambiguity at the different layers and we might start over architecting overdesigning or just designing the wrong things because we're paying too much attention to the stuff that doesn't really matter because it's too broad in definition so going smaller really helps us focus on this vertical slice and if you're thinking about all the layers I'm trying to talk with my hands when I do this but when you're thinking about all the layers you have to cut through the more narrow that slice can be the better off you are in terms of your focused efforts in those different layers that you have to go touch and this can be really valuable from a testing perspective too again when it's a really broad slice instead of a nice thin vertical slice your impacted areas that you're touching that are going to need regression coverage against them new tests added the surface area of your application in general is much more broad but with a vertical slice you can help narrow down just the pieces that you have to go test to make sure that everything is still working as expected and again coming back to being pragmatic one thing that I wanted to call out is that yes while I've been talking about making these slice is more thin cross cutting just a narrow part of all of these layers one of the things I mentioned was that it gives you sort of this laser focus but something else that you'll want to think about is that we can't just ignore dependencies so in the invest principle I was talking about making these user stories not dependent on each other but I think if we totally ignore sort of the architectural direction that our software is heading in it's a recipe for disaster so we don't have to have it carved in stone it's not like today we decide the architecture and then tomorrow a week from now 2 years from now it must remain the exact same I think that's a real recipe for disaster because there's no flexibility so I do think that there is a balance when you're trying to get these thin vertical slices that you want to be focused on just what you have to touch but also keeping in mind what the architectural direction is for the software that doesn't mean that you have to go implementing all of the changes across all of the horizontal as you're delivering your feature but totally ignoring the direction that those those horizontals want to be heading in I think that that's going to kind of cause some issues or more work down the line and again one more thing about being pragmatic that's a big theme for me in software engineering is that yes you might start out developing these vertical slices within your team so you have you know people contributing to quite literally the the slices down uh across all the horizontals but what might end up happening is that you have people that as you're starting to do the work they find that they're blocked on the different layers making progress for some reason right it might be that the team doesn't have a lot of practice kind of doing this kind of thing it might mean that there was a misunderstanding about sort of the progress of different layers and then trying to glue them all together through this vertical just isn't going to line up right now and what you might end up with is that you have team members kind of focused on the different horizontals for too long so maybe the database was just having a ton of problems it wasn't really configured the way people were expecting and there's just more investment going into that layer right as that's happening and then maybe the next layer above for the business logic interacting with that there needs to be some extra investment there you start to kind of fall back to this layered approach where you have people investing more time specifically into the layers and less about addressing this vertical sort of as a dedicated feature but I just want to say that that's okay right it's it's software we're humans it's not going to be perfect the the idea here is that we're trying to head in this direction to have vertical slices but in practice if it's not actually working out it's okay but like I said earlier you're going to want to have a retrospective process in place so that you can ask yourself really difficult questions about why wasn't this working and I think it's just such a good opportunity for you and your team to learn and then get better for next time so that's it for implementing vertical slices again it's something that you're going to have to practice so I didn't want to share this information with you with the expectation that now you're an expert everything's going to be perfect and work smoothly forever in every attempt that you make at this and honestly it's just like writing code in programming right it's going to take practice to try and master this so do expect that it's going to be challenging the first time that's totally okay you're going to want to think about trying to have user facing stories right functionality for the user thinking through it end to end and then how that's going to span the different horizontals you have and that way the more Focus you have in those spaces the more dedicated time you can have for delivering those features so thanks so much for watching I hope that you found this insightful and we'll see you next time