Slice down the middle, not into layers

You have two weeks and a reconciliation view to build. There are two obvious ways to cut it up.

By layer. Week one: the schema, the query, the API endpoint. Week two: the UI that consumes them. This is the natural cut, because it matches how the system is organised and how you think.

Down the middle. Day three: one account, one date range, hardcoded, rendering a real difference from real data. Then widen it.

Both are two weeks of work. Only one of them can be checked by Marta.

The definitional problem with layers

This is not a claim about speed, and I want to be careful about that, because the tempting version of this advice promises speed and cannot deliver it.

A horizontal slice is, by definition, a change with no observable behaviour until somebody else’s change lands on top of it. That is what makes it horizontal. Which means for as long as it is the only thing that exists, there is nobody outside your team who can tell you whether it is right.

Every question that matters stays unanswered. Is the difference calculated the way finance calculates it? Does the date range mean transaction date or posting date? Is the thing Marta needs even in this dataset? A perfect API with the wrong semantics is indistinguishable from a correct one right up until the UI arrives, and then you have a week to fix a design decision you made twelve days ago.

Bill Wake put the risk plainly back in 2000, in the XP era where this idea comes from:

“By doing a skinny version, you’re exercising all parts of the system, so you find out early on if there’s a problem with any part.”

His warning about the alternative is the sharper half: skip the vertical slice and “you run the risk that the customer gets stuck with a well-designed part of a system that can’t” do anything for them yet.

BY LAYER                          DOWN THE MIDDLE

d1-3   schema + migration         d1    hardcoded account, hardcoded
d4-6   query + aggregation                dates, real query, ugly table
d7-9   API endpoint + tests               -> Marta looks at it
d10    (integration begins)                  "that's posting date.
d11-14 UI, and everything                     I need transaction date"
       you got wrong
                                  d2-4  fix that, add date picker
first checkable moment: day 10    d5-8  widen to all accounts
                                  d9-14 the parts she said mattered

four days to absorb every         every day after day one is a day
wrong assumption at once          somebody could have corrected you

The vertical version is not faster. It is not obviously less work. What it is, is checkable on day one, and every day after that is a day on which a wrong assumption costs one day instead of twelve.

The move

Cut the work so that the first thing you finish is something the person who asked for it can look at and judge.

Thin is allowed to be embarrassing. One account. Dates typed into a constant. No pagination, no empty state, no loading spinner. The only property that matters is that it goes all the way through and produces a real answer from real data.

What I am not claiming

Nobody has measured slice orientation against delivery outcomes. There is no study showing vertical slices ship sooner. The argument above is definitional and about risk timing, not about throughput.

And smaller does not mean faster through review. A study of 845,316 pull requests across a hundred popular projects found pull request size and composition “do not relate to time-to-merge”, confirmed across two other review platforms. If somebody sells you vertical slicing on the promise that it gets work merged quicker, they are guessing.

What the delivery data does support is the direction: DORA finds that working in small batches “amplifies the positive impact of AI adoption on product performance”, which matters more now that the volume of change per developer has risen sharply and review capacity has not.

What it costs

A vertical slice touches more of the system at once, which means more files, more contexts, and more chances to be interrupted mid-cut. Layers are genuinely more comfortable to work in, and that comfort is why teams drift back to them without deciding to.

You will build some things twice. The hardcoded query on day one becomes a real one on day six. That rework is the price of the feedback, and it is nearly always cheaper than the alternative, which is discovering on day ten that the whole shape was wrong.

And thin slices are easy to mistake for finished ones. Somebody will see day one’s ugly table and ask whether it can go out on Friday. Be explicit that it is a probe, not a product.

Try this week

Look at the ticket you are about to start and write down the first moment somebody outside your team could form an opinion about it.

If that moment is more than two days away, you have sliced by layer, whether you meant to or not.

Then find the thinnest possible path from real input to real output. Hardcode everything that is not the question you are trying to answer. Get it in front of the person who asked, and open with:

This is deliberately ugly and only works for one account. Before I build the real one, is this the right number?

The answer to that question on day two is worth more than anything you could have built by day ten.