Eating Toast

There are two ways to break down a project (OK, there are probably more than two ways, but work with me here…)

One way is horizontally, meaning to implement an entire application layer at once. This would be like building the entire UI first, then the business layer, then the database, etc. The other way is to implement bits and pieces of all layers over and over, which is like taking a vertical slice through a program — a bit of UI, business logic, persistence, and so on. When people are first learning Agile, it seems to be difficult to get their heads around what taking a vertical slice actually means and why they would want to do it. They need everything built before anyone would possibly want to use their creation, so vertical versus horizontal doesn’t make any practical difference to them. It becomes my job to explain why vertical is superior in most casts. So I’m talking to a manager here, trying to find the right words to allow him to understand what I’m trying to say, and I stumble upon this metaphor, Eating Toast.

Let’s say we’re going to hold a dinner party and we’re responsible for preparing the feast. This act consists of 4 separate activities: Shopping, Cooking, Eating, and Cleaning. If I were to implement this task horizontally, I’d learn how to shop really, really, really well, and fill up my grocery cart as well as anyone else in the entire world. But, who cares? I can’t do anything with the food, so I’m left with this pile of food and no way to make use of it. Ah, so now I need to learn to cook. Now I can take the food I bought and do something with it — I can cook it! But, again, who cares? Having plates full of cooked food is not useful to anyone if you don’t know how to eat it. And the story goes on, through the eating and cleaning phases of our dinner project/party.

Now, an alternative way of looking at this is that, instead of learning how to be the world’s best shopper, cook, eater, and cleaner before I can actually have my party, maybe I can learn how to shop for, prepare, eat, and clean up from a simple meal of a piece of toast. If I want to throw a Toast-Only Dinner Party, I’m now set  I’ve learned how to buy, cook, eat, and clean toast. Next, I can learn how to cook waffles, followed by sandwiches, etc, each time making my potential dinner party more lavish and elegant. Dish by dish, I can learn how to expand my knowledge beyond Eating Toast.

After hearing this metaphor, the idea of vertical versus horizontal made sense. Does it make sense to you?

Yours, with crumbs,




6 thoughts to “Eating Toast”

  1. Seems to me that another insight is that when you take a slice πŸ™‚ through the process, you have to trace intention backwards from the end goal. In other words, it doesn’t matter how well you can shop if you don’t know what you’re making. You need to trace backwards from serving toast –> cooking toast –> buying bread.

    Similarly, in a vertical slice of a system, you need to trace backwards from story –> acceptance test –> unit test –> code.

    Hope that’s not a crumby πŸ™‚ extension to the analogy.

  2. Good analogy.

    Speaking of which, using your so-called vertical approach (if i haven’t mistaken the agile approach), how do you go about designing your tiered app, do you still create your data access layer (DAL) and business layer and if so how do you go about doing it?

    I believe in agile approach and that it’s in fact more efficient if you get the right balancing act. Having said that, i also believe in tiered app, and so recently i’ve used a different approach to create the DAL in such a way that the DAL can be implemented using the vertical approach, this way multiple developers can add to the DAL as neccessary without affecting each other. The way that the DAL was implemented was to use name space instead of classes to group data access methods. Each data access method is created as single class which have a 1 to 1 mapping to a stored procedure. I’ve found that this approach works really well in a multi-developer environment working on a business app, primary because it removes a lot of dependency on the DAL which multiple developers might be working on at the same time.

  3. Sasa,

    Yes, vertical partitions are, by definition, things the user can see. That’s a big part of why they’re so valuable. Since they can see them, they can almost immediately validate that what you’re building matches what they think they’re asking for.

    If you build internal layers of your application for a long time and don’t show the user anything, you’re depending on their faith in you to keep funding your project, and you’re depending on your luck to ensure that you’re actually building the right thing.


  4. Yes, I still do create those layers. They generally come about due to refactoring and paying attention to the Single Responsibility Principle.

    I like your idea about how to split up the DAL into smaller classes, my only fear about it is that it might be difficult to find the exact method that you need. The reason we put related things into classes is to help us find them when we need them. If we’re operating on a customer, then chances are we will need several operations on that same abstraction. By splitting them out, it seems that it might be harder to find the right one at the right time. Or it may not, since I don’t see your code.

    Also, in a smaller team, this approach may be unnecessary, since you’ll all be co-located.


  5. Brian,

    Yes, this is how I understand it. The reason I asked is, because I wandered why is the metaphor needed.

    Your explanation in response to my original comment is very clear, simple and non techie. I would expect that someone from the upper management should be able to comprehend and realize such explanation.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.