First Slice of a Project

Imagine a small feature runs on a laptop, produces the right output, and impresses everyone in the room. It is tempting to conclude that the hard part is over. Source material on this topic argues the opposite: writing code has become the inexpensive part of building software. Generating a working function or a small module is now fast, so the bottleneck has moved somewhere else.

The central claim is that writing code is often only about 20 percent of the problem. The other 80 percent is determining how the code will be tested, reviewed, deployed, and maintained across the organization that depends on it. This article explains why that remaining work deserves deliberate design from the beginning, and how the idea of a first slice helps a team do that.

To see where the bottleneck sits, follow a piece of code after it is written. It has to be checked, read by another engineer, placed into a real environment, and then kept working and changeable for months or years. The diagram below shows that sequence. Each step asks something different of the code, and the arrow returning from maintenance shows that what happens later feeds back into new changes.

The four activities in the source each place different demands on the code. Testing asks whether behavior can be checked reliably. Reviewing asks whether another engineer can read and understand what was written. Deploying asks whether the code can be moved into a real environment and run there. Maintaining asks whether someone can change the code safely long after it was first written.

The word slice implies a cross-section. Instead of building every layer of a system completely before anything runs, a first slice cuts through all the important parts at once, but thinly. Because it is small, it also gives the team an early chance to discover structural problems while they are still cheap to fix.

Notice what a first slice does not contain. It does not describe a fully featured product. It describes a unit that works, is small enough to review, and can be shown to others. That is the practical meaning of a first slice, and it is what allows the surrounding 80 percent to be designed for early instead of postponed.

The example below is an illustrative one written for this article, not taken from the source. It shows how a team might trace one thin path through a small notes feature, touching each important part of the system once before adding breadth.

Each of the four activities in the surrounding 80 percent asks a specific question of the code. The table summarizes those questions. A slice built with only the first activity in mind, usually testing or simply getting it to run, may do well in a demo and then struggle with the other three.

Deferring testing, review, deployment, or maintenance concerns is a common quick-fix pitfall. The problem usually does not appear during the demo, because the demo succeeded. It appears afterward, as the team tries to test, review, deploy, or change code that was never shaped for those activities. The timeline below shows that typical order of discovery, based on the pattern the source describes.

The sequence in the diagram is an illustration of the pattern, not a fixed schedule. Any single project may surface these problems in a different order or not at all. The lesson is that the cost of finding them late is paid by people who must rework code that was never designed for those activities.

Designing for maintainability means considering the surrounding work during initial design rather than deferring it. Restraint in engineering means recognizing that the remaining work deserves deliberate design, not a last-minute scramble after the code already exists. In practice, this means asking the four questions from the earlier table while the first slice is still being shaped.