Slicing
Tags: webdev, ux, agile
Published: 2022-12-12 02:46:27

When first developing a website, developers would sit together, think of the idea/purpose of the application, then sit through to discuss database schema, front end styling, back end functionality, etc. Essentially splitting up each big "chunk" of software to design and detail the purposes and minimum viable processes it would require and handle. 

## The Horizontal Slice


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7wqf3intzbqbfwwlchmk.gif)

The above references typical software development planning as **horizontal slicing**. This isn't a bad approach, and seems fairly practical for development work split amongst a dev team. The only concern is that it does not consider the user's experience and interaction with the product, or as it's called the **User Stories**. In agile development, especially where the end product is meant for millions of users, it is wise to prioritize and pivot the perspective of development towards the User Experience.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/niaxn72z7hikxqiki30y.png)

Splitting your code up into functional layers, like how the cake presents, is great to cleanly organize what and how certain programming is done, but in the end you can imagine that a horizontally sliced cake does not give a user an even bite of the entire product.

In more practical terms, issues that arise with horizontal slicing include

- A stakeholder not being able to see progress/parts of the project until it is completely finished

- Feedback from the stakeholder can change the product entirely if one small feature doesn't match (since the entire app was already an Minimum Viable Product (MVP)

- Evaluation of smaller user stories is delayed until all parts are completed, which hinders data scientists' ability to evaluate success
 

## The Vertical Slice


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/slopg0bqnxdu4zn46ewp.gif)

The main aspect of vertical slicing is thinking in "slices" of user stories. For example, first develop a login/signup feature that stores the encrypted data in the database and can hash it when needed, while simultaneously routing the frontend to handle unauthorized users to a signup page and redirecting them once authorized.
This approach allows you to work on all aspects of the app and only develop what is needed for that initial vertical slice. The backend is developed enough to handle new and existing user calling, and the frontend can handle routing and redirecting from a home page and signup page, vice versa.
This also yields a better showcase to the stakeholder, only showing the minimal pieces developed in perspective of the user so that when the inevitable rash and absurd changes are asked for, it is slightly tolerable since there is less of the app to "rework"

Other benefits include
- Data scientists being able to evaluate a lot earlier
- The dev team being more aligned with the stakeholder's ideals and needs without completely forfeiting their own ideals of how the product works behind the scenes.

## Conclusion

Both flows of development are great in their own regards. I would even suggest horizontal slicing if you are making a simple app for yourself. But for larger scale, and especially in teams, vertical slicing seems to cover all grounds of management error while still progressing your code

## Resources

Data Science Process Alliance <https://www.datascience-pm.com/vertical-vs-horizontal-slicing-data-science-deliverables/#:~:text=Traditional%20software%20approaches%20favor%20developing,value%20streams%20(vertical%20slicing).>

Visual Paradigm <https://www.visual-paradigm.com/scrum/user-story-splitting-vertical-slice-vs-horizontal-slice/>

mondayBlog <https://monday.com/blog/project-management/vertical-slice/>