How Working the 'Vertical Slice' Can Fix your Coding Mental Block

Making something “just work” and “good enough” was ok when you were a junior developer. But now that you’re in a more senior role, it’s easy for your mind to freeze when it’s time to sit down and code. You feel like you’re over-thinking your code because you know:

There’s nothing wrong with wanting to everything right the first time. But it can be a form of “writers block” that cripples your productivity.

A common recommendation is “first, make it work - then go back and refactor”. A fine recommendation, but you’re having trouble sitting down and puking code into your IDE. You want to minimize that “go back and refactor” time because - *is that time really going to be available next month?*

When your productivity is suffering and your boss is noticing, what can you do?

We talked about building a walking skeleton in order to establish internal and external feedback loops. But how do you code faster by focusing on tests?

Let your tests be a concrete guide for your implementation.

When you start working on a feature, try to forget about the implementation. Forget about the technologies, the database, the web servers, and focus on behavior, i.e. what the system should do.

Start with a vertical slice

The vertical slice comes from Agile and the idea of incremental over iterative development

Incremental Development “builds a system feature by feature, instead of building all the layers and components and integrating them at the end” while Iterative Development “progressively refines the implementation of features in response to feedback until they are good enough”

Incremental development, if done well, results in the consistent delivery of functionality (Freeman et al)

John Sonmez writes on the “vertical slice”:

“The idea is that instead of breaking a backlog up into the following:

  • Implement the database layer for A, B and C
  • Implement the business logic layer for A, B and C
  • Implement the user interface for A, B and C

The backlog is broken up into something like:

  • Implement A from end to end
  • Implement B from end to end
  • Implement C from end to end”

Acceptance tests

A benefit to working in vertical slices of the application is that it allows you to test broadly first, narrowing the scope as you go.

These tests, called “acceptance tests”, pass when all of your unit tests pass. They help you to “clarify what you want to achieve”…

“The failing tests keep us focused on implementing the limited set of features they describe, improving our chances of delivering them.” (Freeman et al)

By clarifying what you want to achieve and using smaller tests to guide your implementation towards passing your acceptance test, you can stop making assumptions… you can worry less about making bad decisions up-front.


Imagine you’re a climber who is about to scale a cliff. You need to plan your ascent. Do you think it’s easier to plan the entire ascent from the bottom? Or place anchors and re-evaluate your plan every 20 or so feet? Which one will be faster?

I’m betting that you’ll learn something about that cliff somewhere along the way that you didn’t know when you were standing at the bottom.

Same with your code - your tests are anchors that you place along the way so that you can re-evaluate, and even change your plan as needed.

At the same time, if you’re focused on delivering a vertical slice(s) of functionality, you can listen to your tests rather than your assumptions. This helps you to actually write code and build momentum through your project.

Make sure you sign up for my newsletter to be the first to get my latest articles!

Related Posts:

comments powered by Disqus