I recently finished reading Shape Up by Ryan Singer and it's changed the way that I approach building software. I came across the book because my manager linked to it during a Scrum workshop for our dev team. What made it stick out was how it advocated for 6 week development cycles instead of the typical 2 weeks. Coincidentally that same week, I had come across Pavel Tsatsouline talking about how the perfect cycle for improving performance in the human body is 6 weeks, which is also 42 days (meaning of life anyone?). I had always felt that 2 weeks were far too short to do anything meaningful; by the time I got my head around a particularly hard problem, the sprint was almost over and it would be a race against the clock from there (spoiler alert: the clock typically won). Six weeks hits that sweet spot because it is a bit longer than a month so you can potentially do something ambitious, but it is shorter than 2 months which means you don't have time to get distracted.

While the 6-week cycles drew me in, the most important ideas I learned were on how to approach building the software. Specifically, given a blank slate, where do you even start? I'd never even thought about this question. I would usually design the whole thing and then start coding one of the pieces and go from there. Usually what I started with was something easy and/or familiar. But this is actually not the best use of the early stages as it can waste the momentum and excitement inherit to the inception of a project.

Start In the Middle

Ryan suggests using the first couple of weeks to ship a complete vertical slice of the app that completes one action. But not just any slice, specifically you want to "start in the middle" with a slice that takes most of the uncertainty out of a project. When I think of uncertainty, I usually think an action in the UI that causes a write of some sort. This is not always the case because rendering some complicated piece of data could actually be the most uncertain portion of your application. But as a general rule, writing data is riskier and typically harder to get right so these are typically the slices that you want to focus on.

Work is like a hill and every piece of work has two phases — uphill and downhill.

Focusing on the riskiest part of the flow also sets you up for the rest of the project. Ryan suggests that there are two phases of work: the first phase where we figure out what we want to do (this is the uphill portion) and the second phase where we know what all the steps are and we simply need to execute. We talked about how the start of a project has some initial momentum built in. You want to find the vertical slice that makes most of your work downhill work after you are done with it. Using that initial momentum to build up the riskiest piece helps you climb pretty high on that hill and you can set yourself up for some downhill work the rest of the way.

In economics there is a concept known as the Pareto principle, also called the 80/20 rule that states that 80% of the consequences come from 20% of the causes. Here we want to uncover 20% of the work that eliminates 80% of the uncertainty. Figuring out what this piece is takes some work, but the strongest indicator I've found that I'm on the right track is fear or lack of confidence that I'll be able to build that part of it correctly. I now build those pieces first. At best, these pieces aren't as hard as I thought and I end up with working software very quickly. At worst, these pieces are really tough and I can get to the heart of the matter really quickly while my enthusiasm for the project is still high.

Another way I've been thinking of this is -- similar to how a valuable integration test exercises most of your components, the most valuable vertical slice also touches a lot of components. They don't have to be complete versions of those components, but by integrating all these pieces to complete the action you can reduce the uncertainty around how things will wire up.

Perhaps a more "complete" example is warranted here. Given what I now know, if I were building a video app similar to youtube, the first thing I would build would be the upload piece since this would touch pretty much all the different data stores by system would hold. It would touch object storage, the task queue that handles processing the video, it would touch the video metadata and also touch the user database to store the video to user relationship. By having this one upload piece fully working, the rest of the app would be pretty much downhill work from there. We could bolt on search, auth, recommendations and rendering/playback after the fact since those systems would use most of the components we would sketch out while building the upload piece. Granted, those pieces could still have their own uncertainty hills to climb, but we'll talking of global maxima here.

I'm glossing over quite a lot of details in that example. But hopefully you can see the logic in the ideas behind it. I've certainly found it helpful in the last couple of projects that I've worked on and I hope I've done Ryan's ideas justice. Either way, I'd highly recommend reading the book for yourself as there are other gems in there that I didn't touch on.