Shipping Software in Small, Verified Slices

The eleventh week

I came into software in June 2023, and it did not take long before I was sitting in the version of the meeting that everybody in this trade eventually attends. Weeks of work were behind us. There was a great deal to show. The client had been patient, in the way clients are patient right up until they are not. Then somebody clicked the one button that actually mattered, and nothing happened.

Nobody in that room was lazy or unskilled. The code was real code. The problem was structural. We had arranged the project so that the first honest test of whether the thing worked arrived at the very end, at exactly the point where being wrong was most expensive and least forgivable.

That is what a big-bang launch is. It is not a delivery strategy. It is a decision to save all of your bad news for the same afternoon.

It keeps happening because everything around a project pushes towards it. Contracts get written in phases with names like design, development, testing and deployment, as though a system were a building that must be roofed before anybody can walk in. Deposits arrive at the start, so pressure to demonstrate progress comes long before there is anything a person can use. And there is pride in it. You want to show the client the whole thing, finished, working, in one confident sweep, because showing them half a page feels like admitting you have not done much.

So the developer builds the database layer, then the API layer, then the interface, and every one of those weeks looks productive on a status report. But none of those layers can be used by a human being. A schema cannot register a member. An API with no screen cannot be put in front of the person who will actually be typing into it. You are three weeks in with nothing that can be tested by anybody who is not you, and the client’s confidence is being spent on your reassurances rather than on evidence.

What a vertical slice actually is

A slice is thin in scope and complete in depth. That second half is the part people drop, and dropping it is what turns the idea into a buzzword.

Take a registration system. The horizontal instinct says: this week, all the tables. The vertical instinct says: this week, one person fills in one short form, it saves to the real database on the real server, and an administrator opens a real page and sees that person’s name. No payments. No dashboards. No attendance tracking. No reporting. One name, end to end, on infrastructure you do not own and cannot restart from your terminal.

The same four layers, built two ways.

That slice is embarrassing to demonstrate. It is also usually the most valuable week of the whole project, because everything it touches becomes proven rather than assumed: the deploy pipeline, the database connection, the form validation, the read path, the permission model, and the plain question of whether the client’s browser on the client’s network can reach your server at all. Every later slice inherits that proof and stops paying for it.

The horizontal approach postpones all of those questions and then asks them simultaneously, under deadline, in front of an audience. It also hides a subtler cost. When you build layer by layer, you make hundreds of small decisions in the abstract, with no feedback, and a fair number of them will be wrong in ways that only become visible once a real interface sits on top. By the time you find out, the wrong decision has three weeks of code built on it.

There is one further advantage that has nothing to do with engineering. A slice is a sentence a non-technical person can check. Anyone can evaluate the claim that a member can apply online. Almost nobody outside the team can evaluate the claim that the service layer is complete.

Verified means somebody opened the running thing

I want to be precise about the word verified, because green tests have made a lot of people comfortable while their software was quietly wrong.

Tests confirm that code does what the code was told to do. They cannot tell you whether what it was told matches what a user needs. When I was configuring Ozone, an OpenMRS distribution, for a facility in Burundi, I ran manual testing cycles against the requirements, screen by screen. Automated checks would have passed on nearly everything I found. A form can save perfectly and still write its value to a concept that nobody reports on. A user role can be created exactly as specified and still lock a clinician out of the one page their job depends on. The code was fine. The configuration was answering a question nobody had asked.

The same gap shows up in infrastructure. When I deployed OpenMRS instances on AWS using Docker, Ansible and Terraform for a client in Botswana, a clean apply told me that resources existed. It said nothing about whether a clinician could add a lab test. Those are different claims and only one of them is worth money. I have watched a deployment be declared successful by every dashboard in the chain while the thing the client bought did not work.

So verified, for the purposes of a slice, means one specific thing: a person who is not the author opened the running system and completed the task from start to finish. Not the build. Not the log line. Not the pull request approval. The task. If nobody has done that, the slice is not done, however much code exists.

Four signals that can all be green while the thing the client bought does not work.

This standard has a pleasant side effect. It makes the definition of done impossible to argue about, which removes one of the most common sources of friction between a developer and a client who each believed something different about what week four would produce.

Two projects, the same lesson

We built the public site for NUTOFA SACCO, a savings and credit cooperative whose members are farmers. The easy plan would have been to design every page, approve it all on paper, build for six weeks and reveal it. Instead the home page and a working contact route went live on the real domain early, then membership, then the savings products, then the agricultural mechanization services.

That ordering paid for itself in an unglamorous way. The equipment section, as first written, described a fleet larger than what the cooperative actually owned outright. Because the page was already live and being read by people who work in that yard, the correction came back within days and the site was fixed. Had that copy sat in an unpublished draft until handover, it would have gone out at launch and from there into banners, pull-up stands and business cards, because printers do not wait for your review cycle. Publishing early does not only find bugs. It finds untrue sentences, which are more expensive.

The second project was a church camp registration and management system I built pro bono, React on a .NET backend. Camp meetings have a property most software projects would benefit from: the date cannot move. Nobody reschedules a thousand people because a developer needs another sprint.

So we sliced it small. First slice: one registrant, one list, nothing else. Within the first handful of real registrations something became obvious that no requirements discussion had produced. People were not registering as individuals. They were registering whole families under one name, and the form had no room for that at all. We learned it in the first week, from real people typing real names, instead of on the Friday before camp when the phones would have been ringing.

A big-bang build would have found the same problem. It would have found it too late to do anything except apologise.

Selling it to a client who wants everything at once

The objection is fair and you should expect it in plain words: I am paying for a complete system, not for pieces of one. Arguing about methodology will not move anybody. What works is showing that they are not buying less, they are buying earlier sight of what they have already bought. A few things make that land:

• Write the entire scope down first, in one document, and get it signed. Slicing then reads as sequencing rather than shrinking.
• Tie payments to slices the client can operate themselves, never to internal milestones like backend complete.
• Give them a login on the very first slice, even when it does almost nothing.
• Name each slice in their language. A member can apply online. A treasurer can print the list. Not auth module, not reporting layer.

Underneath the objection, clients are usually not asking for a big launch. They are asking for certainty, because most of them have been burned by a developer who went quiet for two months and then asked for more time. A slice every fortnight gives them evidence they can check without trusting you. A big launch gives them a promise, and they have heard promises before.

Staged delivery also changes who the client becomes. When somebody is using your software from week two, they stop being a reviewer of documents and start being a source of the specific, awkward, valuable detail you could never have guessed on your own. The family registrations. The equipment that was not really theirs. That information does not arrive in a requirements workshop. It arrives when a person with a real task in front of them walks into a wall you built.

Software does not become real when it is finished. It becomes real the first time somebody who is not you uses it to do something they genuinely needed to do, on a server you do not control, over a connection you cannot see. Every week you postpone that moment is a week spent building on a guess and calling it progress. I would rather be wrong on a Tuesday about one page than right in principle about thirty.