Breadth-First Development

Tuesday, June 09, 2009 5:46:41 PM (Romance Standard Time, UTC+01:00)
I first came across the term vertical slice when I was in the video games industry. Trying to raise capital for our game, we were told by venture capitalists that they needed to see a vertical slice in order to assess our concept. That meant a small version of our game with just a little bit of everything. You should be able to see the technology, the artwork, audio, game design and all. I am not sure where the term originates from, but it is easy to realize what it means. If you consider a product to be composed of layers, the vertical slice represents a little bit of each layer.
Vertical Slice
This blog is called The Vertical Slice for a reason. While there is great focus on prioritizing in agile development, the emphasis is often in the concept of "business value". Which is a very sound focus compared to say, premature optimization or writing a system that is unnecessarily generic. However, focusing on vertical slices is equally important. As my colleague Lars suggested recently, the term breadth-first development is perhaps even more descriptive. If you consider the product to be a tree of increasingly detailed features, you want to start at the top and move into the details at all levels at the same time.
Breadth-First development
There is a consequence to this: you run into a lot of problems at the very start. A project that we are currently working with includes a web-frontend, a database layer and a reporting system that have all given us different kinds of problems. Other teams might have focused on getting one part working before moving on to the others but in the spirit of breadth-first, we wanted to work a little bit with all of them. That way, we don't run off on tangents in one of the layers, which might turn out to be unfeasible or simply incompatible with the rest of the environment.

By Kristian Dupont