Brendan Enrick

Daily Software Development

We Slice Software Vertically Just Like Bread

Bread When working on a feature or some other aspect of a software project, it is important to figure out what piece you want to do at any given time. There are two primary routes you could take. Perhaps you want to go and create the whole UI, but have nothing wired up. Maybe you want to go and write all the business logic first, and you might want to go create the data layer and underlying infrastructure. If you do one of those then I will call you crazy.

I believe in vertically slicing an application. You never know at the beginning of a project what scope creep is going to occur, and you also don't know which aspects of your initial design will be completely unnecessary. One of the main reasons why so many people are against "big design up front" is because we don't know what we're going to need in the end.

If we're working in vertical slices, we can complete an entire piece of functionality that we know we need. This is why we work with vertical slices. We can stop at any time, and there are no unused pieces. Everything we've completed is there and working.

If we ignore how references in our application might be set up and just look at the structure of an application with a very simplistic view, we might say that there is a UI that calls some form of business logic which in some way talks to some kind of data.

Basic Structure of a Project


Say for example that we are going to work with a horizontal slice. Yes, plenty of people do this. I tried working on an application this way many years ago. So perhaps we are thinking, "hey, why don't we get the database and the data layer hashed out at the beginning then we can just write all the code on top of it later." After working on this for a while we might end up with something like this. The blue is the completed work.

Work Done Horizontally


Now for some questions.

  • How much can we show the customer? Nothing.
  • Are we sure we structured everything the way the customer wanted? No.
  • What if this is an open source project, maybe we want to encourage other developers to join the project. Are these developers able to see the structure of our application and how we want things to work? Well it looks like.... no.

Now what if we had done the same amount of work vertically? We might end up with something like this.

Work Done Vertically


Now assume that this is the same amount of work as if we had worked horizontally. Sure we have a lot less breadth, but the depth of our work is far greater. Now if we ask those same questions.

  • How much can we show the customer? Everything we've worked on.
  • Are we sure we structured everything the way the customer wanted? Yes, because the customer can see it and can tell us right now if we did something wrong. We are able to quickly respond to and fix the problem.
  • What if this is an open source project, maybe we want to encourage other developers to join the project. Are these developers able to see the structure of our application and how we want things to work? They can see everything we've done. Anyone hopping on this project would see the full structure and know how the layers are interrelated and would likely be able to add meaningful work to the project.

My Past Horizontal Mistake

So I mentioned early in this article that I tried horizontally working on a project once.  Yeah, that was a mistake. As you get to new aspects of a project a little thing called scope creep occurs. As you get to and think about new pieces of an application you realize new ways you can improve them, right? Well, this is another major problem with working horizontally. As I added new pieces, I came up with new stuff I wanted to do. New ways of doing things came to mind. Eventually I had scope creeped the data enough that I ended up giving up on the project.

I've recently started working on the project again, but this time I am of course working with vertical slices. I am going to make pieces just large enough to give me some value. That way at any point I could stop development and have a working tool. One which does something. Maybe not everything I want, but enough.

A Skill to Learn

Breaking tasks into thin vertical slices is difficult. Without advances in bread slicing technology, the processed, sliced bread from stores could never be so thin. It isn't easy to make thin slices, but the thinner the slice the better we are able to get the amount of bread we want. Perhaps we want 3 slices. Before we had these thin slices it might have been one and a half, but the thin slices make everything easier.

Some tasks look like they'll take weeks to complete. That my friend is not a task. We need to split that. There is probably some aspect of that which could be completed in a day. Maybe it wouldn't be in a shippable state, but there would be something that the customer could see. An initial bit working that is not the whole thing. This gives us two things. It shows the customer what we're working on, and it also gives them the chance to give us feedback. We can more easy adjust that small slice than if we had delivered the whole feature at once.

A Slicing Example

Assume we have a web site. We want to add user profiles to the site. Our customer comes along and says he wants the profile to have this information.

  • Full Name
  • Nickname
  • Location
  • Age
  • Gender
  • List of current and previous occupations
  • List of educational institutions
  • List of favorite games
  • List of favorite movies
  • List of favorite books
  • List of favorite songs
  • List of favorite musicians
  • List of favorite places
  • List of friends

If you went to do all of this at once it could take you a while. This is a good time to figure out some nice places to split things. An obvious split here is to do everything that is not complicated. For this we could say the top 5 ones we'll do. These don't have lists.

Slice 1: Create Full Name, Nickname, Location, Age, and Gender as a profile and create a view and edit page for them.

That slice is very manageable, and when you're done you can show the customer and make sure that is what they were expecting. Perhaps they wanted Full Name to be 3 separate pieces: First, Middle, and Last. Since we haven't done much, this is easy to change right now.

Now we might say that the next slice is the next item on the list. Why? Because we want to get one of the lists in place and the functionality set up and to the customer for feedback.

Slice 2: Add a list of current and previous occupations to the user profile.

Ok so we implement this basically as a list of strings. The user puts in the name of the occupation and adds more in the same way. We display this list of occupations on the profile page. Now when we show the customer this he says that he wants the list to intelligently suggest occupation names as the user types with previously used occupations. So now it is a bit more complicated, but we make the change. We then ask if the same will be done with the other lists, and the customer says "yes". Now we know how to do these next ones.

As we work through the next few slices, maybe the customer decides that we don't need both musicians and songs. The customer gets rid of musicians. Well we benefit here, because we hadn't put any work into that yet.

I really want to emphasize here that a slice should be small. Vertical slices are there so you always have a working product. At any moment you could stop. Maybe we stopped before doing the lists of things. We had a working solution at that moment. The other big reason we do vertical slices is so people can se what we've done and give us feedback. Customers might give you feedback on the UI, but until it is wired up and working the feedback isn't as useful.

Breaking Down Customer Stories

Creating stories to work on is an integral task in agile software development. These stories are what the team of developers will be working on for the iteration. Where do the stories come from? Well, through discussion with the development team, the customer says what he wants. What types of stories does the customer ask for most of the time? The customer asks for epics. What makes them epics? They're just too large.

When writing software in an agile manner it is important to have very small pieces. You want something that can be completed quickly and delivered to the customer. Sure, it might be a small piece that isn't of much value yet, but that is good. The fact that it is small means that you can be constantly finishing pieces of the project. If your stories are too large you'll only be delivering at the end of the iteration. That's just not cool.

Steve Smith wrote a great blog post where he discusses very well how to break epics into vertically sliced stories. One major reason that doing this is of great advantage to you is that you will be able to get feedback from the customer. In Steve's example he talks about a registration page which is loaded with extra data including multiple addresses, contact info, and possibly other pieces. I can see a customer wanting to have something like this. So there are two ways we can approach splitting this up.

Splitting Horizontally

When you split horizontally, you will be delivering the entire solution at the end since each horizontal slice needs to be finished before anything is finished. So for the sake of argument why don't we say that the developer didn't create exactly what the customer wanted the first time. So now at the end of the iteration the developer finds out that the whole process should have been completely different. Now he goes and rebuilds everything in the next iteration because this one is out of time.

Splitting Vertically

Using this method we will quickly have the first small piece done. We can say that it is the ability just to create a user name and password at registration. Now when the customer sees this we get feedback. Maybe everything is fine for this part. We then go do the next part. Maybe we write the address section incorrectly. When the customer sees this he can let us know. Since we know early that there is a problem we can correct it. We may not have everything done at the end of the iteration, but at least we've got the most important parts done.

Since the customer can keep each of these vertical slices in ranking order at the end of the iteration he will have a bunch of working pieces. He will have stuff he cares about even if it isn't all there. If we had found out at the end of the iteration that we needed to make a change we wouldn't have anything done.


It is important to know how to split stories. Sometimes there are pieces of the story which can be vertical slices, but you should try not to have too many dependent tasks. It will make your software development work much faster and better.