In the realm of software development, the way we structure and deliver our work can significantly impact the project’s success. Enter the concept of “vertical slices.” At its core, a vertical slice refers to delivering a piece of functionality that cuts through all the layers of an application, from the user interface down to the data store. Instead of building out an entire layer of an application before moving to the next (as in traditional “horizontal” development), vertical slicing focuses on delivering small, complete pieces of functionality one at a time.
This approach contrasts sharply with the more traditional “layered” or “horizontal” development or software architectures built in layers. In horizontal development, teams might first build out the entire database layer, followed by the business logic layer, and finally the user interface. While this might sound logical, it often leads to long periods where there’s no tangible output to show to stakeholders or end-users. Vertical slicing, on the other hand, aims to deliver visible, usable features at the end of each slice, even if the application is not yet complete.
And before we dive in, if you haven’t already then consider subscribing to my weekly newsletter for software engineering content delivered to your email every weekend!
Visual Representation:
To better grasp the concept of vertical slicing, let’s use the analogy of a cake. Imagine a multi-layered cake, with each layer representing a different component of your software — the database, the business logic, the API, and the user interface. It can be many different layers, and it’s a lot more obvious if we cut it open with a nice thin vertical slice:
In a traditional “horizontal” approach, you’d be baking each layer of the cake separately. You’d start with the bottom layer, then once that’s done, move to the next, and so on. You could also have different teams working in parallel across the horizontal layers. It might be a while before you have a full cake to present.
In contrast, with vertical slicing, you’d be cutting a full slice from the top to the bottom of the cake, ensuring you get a bit of every layer. Each slice represents a complete piece of functionality, from the user’s click in the interface down to data retrieval or updates in the database. Of course, not every slice will touch all layers, but the concept of cutting across the horizontals is what’s key here. Check out this video for an intro on vertical slicing:
Benefits of Vertical Slicing
Vertical slicing offers a multitude of benefits that can transform the way development teams operate and deliver value. Let’s delve into some of the most significant advantages:
Faster Feedback Loop: One of the primary benefits of delivering in vertical slices is the ability to get feedback early and often. By providing a complete piece of functionality, stakeholders can see, interact with, and provide feedback on a feature much sooner than if they had to wait for all layers of that feature to be completed. This early feedback can be invaluable in ensuring the product is headed in the right direction and meeting user needs.
Improved Collaboration: Vertical slicing naturally fosters collaboration. Since each slice involves multiple layers of the application, it requires input and expertise from various team members, be it database experts, backend developers, or frontend designers. This cross-functional collaboration ensures that everyone is on the same page and contributes to a holistic solution.
Reducing Integration Risks: With vertical slicing, integration is a continuous process. Instead of waiting to integrate various components of a feature at the end, teams integrate as they go. This continuous integration reduces the risk of integration issues cropping up late in the development process when they can be more costly and time-consuming to address.
One important thing I would like to remind readers of is: vertical slicing is not applicable to everything, all of the time, with a perfect fit. It’s something I encourage engineering teams to strive to be able to do, but we must remain pragmatic with all things in software engineering. No silver bullets here.
Starting with User Stories For Vertical Slices
User stories play a pivotal role in defining well-structured vertical slices. A user story is a concise, simple description of a feature told from the perspective of the person who desires the capability, usually a user or customer of the system. This is in contrast to something that might be proposed by the engineering team to tackle tech debt or other infrastructure changes, for example.
Good user stories naturally lead to well-defined vertical slices because they focus on delivering value to the user. Instead of getting bogged down in technical details or specific implementation methods, user stories keep the team focused on what the user needs and why. In fact, specific technical implementation details are NOT included in user stories.
The INVEST principle is a widely recognized set of criteria that good user stories should meet:
Independent: Each user story should be self-contained, in a way that there is no inherent dependency on another user story.
Negotiable: While a user story provides a description of the desired functionality, the specifics of its implementation are open to discussion and negotiation between the team and stakeholders.
Valuable: Every user story must deliver value to the end-users.
Estimable: The team should be able to estimate the size of a user story to plan their work effectively.
Small: User stories should be small enough to be completed in a short amount of time but large enough to provide value on their own.
Testable: Every user story must have criteria that allow it to be tested and validated. (And you know I love talking about testing!)
By adhering to the INVEST principle, teams can ensure that their user stories are well-suited for vertical slicing, keeping the focus on delivering value in small, manageable chunks.
Breaking Down Features:
When approaching a new feature, it’s essential to think about how it can be divided into manageable vertical slices. Let’s consider a hypothetical feature: “Implementing a User Profile System” for a web application.
At first glance, this feature might seem monolithic. But when we break it down, we can identify several vertical slices:
User Registration: Allow users to sign up with basic details.
Profile Viewing: Allow users to view their profile.
Profile Editing: Allow users to edit specific details on their profile.
Profile Picture Upload: Allow users to add or change their profile picture.
Account Deletion: Allow users to delete their accounts.
Each of these slices delivers a specific piece of functionality that provides value to the user. They can be developed, tested, and delivered independently of each other. The decomposition of the original feature into smaller vertical slices is a critical step in ensuring we have more realistic deliverables that meet the INVEST principle.
When prioritizing these slices, consider both the value they provide to the user and their complexity. For instance, “User Registration” might be prioritized first because it’s fundamental to the system and provides immediate value. On the other hand, “Profile Picture Upload” might be seen as a valuable but not essential feature and could be prioritized after the basic functionalities are in place. Check out this video for more information:
Challenges and Common Mistakes:
If you enjoyed this article so far, you can continue reading the full article on vertical slices on my website! Explore some of the challenges with vertical slices along with recommendations for how various tools and systems can assist!
If you haven’t already, subscribe to my weekly newsletter for software engineering content delivered to your email every weekend!
Top comments (0)