Reviewing and Testing Code
Writing code is often only about 20 percent of the problem; the other 80 percent is testing, reviewing, deploying, and maintaining it.
Why Writing Code Is Only Part of the Job
Many beginners assume that a programming task ends when the code runs once on their own machine. Engineering practice tells a different story. Writing code is often only about 20 percent of the problem. The other 80 percent is testing, reviewing, deploying, and maintaining that code over time.
The reason this matters is that 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 elsewhere. This article follows where that bottleneck sits and what engineers should design for as a result.
Following One Change Through the Work Cycle
Think of a single change to a project as a unit that passes through a sequence of concerns. Writing the code is the first stop. After that, the same change must be tested, reviewed, deployed into a real environment, and then maintained by someone who may not be the original author. The diagram below shows these activities as one repeating cycle rather than a one-time task.
Read the diagram from left to right and then notice the arrow that loops back. Maintenance is not the end of the story, because future changes start the cycle again. The writing step sits at one end, but the four activities after it hold most of the effort.
The Four Demands After the Code Exists
The source names four activities, and each one places a different demand on the code. Each demand is a question you can ask about any piece of code you write.
- Testing asks whether the 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 months after it was first written.
A piece of code written with only the first question in mind may work well in a demo and then struggle with the other three. This gap is why the source treats the remaining work as something to plan for in advance rather than discover later.
What a First Slice Contains
A first slice is a minimal, functional, demonstrable version of a project. It runs through the important parts of the system at a small scale, rather than building every layer completely before anything runs.
The word slice implies a cross-section. Imagine cutting through a system from top to bottom and keeping only a thin piece. That piece touches the interface, the logic, and the data, even though each of those is simple. The result is something concrete that can be demonstrated, reviewed, and checked against what the project is supposed to do.
Because a first slice is small, it also gives the team an early chance to discover structural problems while they are still cheap to fix. A first slice is not a fully featured product. It is a unit that works, is small enough to review, and can be shown to others.
A first slice for a small task list
A team wants to build a task list application. Describe what a first slice would contain, and why it is a better starting point than building every feature at once.
- 1Choose one path through the system
The slice adds one task. It does not handle editing, deleting, sorting, or user accounts. This keeps it small.
- 2Include each important layer, even if thin
A user enters the task on a simple interface, the logic validates it, and the data is saved and read back. Each layer exists, but none is complete.
- 3Make it demonstrable
The team can show the add-a-task action working end to end. Anyone can see whether it matches what the project should do.
- 4Plan the other concerns from the start
Even this small slice has a test that checks adding a task, code a reviewer can read, a way to run it somewhere real, and a structure that a later change can extend safely.
The first slice is a working, reviewable unit that exposes structural problems early. It is not the whole product, and the surrounding 80 percent of work is designed for from the first step rather than postponed.
Following a Failed Check Back to the Change
Now trace what happens to a change as it moves through checks. A change is written, then tested and reviewed. If either check fails, the change goes back for more work before it can move on. Only a change that passes reaches deployment. The flowchart below shows that path as a loop with one exit.
The loop is the important part. A failed test or review sends the change back to be reworked and checked again, rather than letting it slip forward. This is where the testing and review demands from earlier become practical: a change that cannot be checked reliably or read by another engineer will keep bouncing around this loop.
Designing In Versus Deferring
Designing for maintainability means considering the surrounding work during the initial design rather than deferring it. The before-and-after diagram compares two ways a team can approach a project. In the first, the demo works and the other concerns are added afterward. In the second, testing, review, deployment, and maintenance are part of the design from the beginning.
The source frames this as a matter of restraint. Recognizing that the remaining work deserves deliberate design, not a last-minute scramble after the code already exists, is the practical discipline it asks for. Maintainability is a property the team decides on early, and the first slice is where those decisions are first tested.
Mistakes That Come From Deferring
Common mistake Treating a successful demo as proof the project is finished
What it looks likeThe feature runs once on one machine, so the team moves on without planning how it will be tested.
Why it failsA demo shows the code can run. It does not show the code can be checked reliably, read by others, deployed, or changed safely later.
Do this insteadTreat the demo as the start of the surrounding work, and ask the four demands before calling a slice done.
Common mistake Building every layer completely before anything runs
What it looks likeThe team finishes the full interface, logic, and data layers before connecting any of them.
Why it failsStructural problems stay hidden until late, when they are expensive to fix.
Do this insteadBuild a first slice that touches each important layer at a small scale, so problems surface early.
Common mistake Assuming a first slice should be a complete product
What it looks likeThe team tries to add editing, deleting, and user accounts to the first version.
Why it failsA first slice is minimal. Its job is to be functional, demonstrable, and small enough to review.
Do this insteadCut the slice down to one working path, and add breadth in later slices.
Common mistake Writing code that only the original author can read
Common mistake Ignoring how a change will be deployed until release week
Checking Your Understanding
A teammate says, Our code works in the demo, so we are almost done and can leave testing, review, and deployment for next month. Using the four demands from this article, explain why this reasoning is incomplete, and describe what a first slice of this project should include instead.
Hints
- Start by listing the four activities: testing, reviewing, deploying, and maintaining.
- Think about whether a working demo answers each of the four questions.
- Recall that a first slice is minimal, functional, and demonstrable, and that it can reveal structural problems early.
Key Takeaways
- Writing code is often only about 20 percent of the problem; testing, reviewing, deploying, and maintaining the code make up the other 80 percent.
- Testing, reviewing, deploying, and maintaining each place a different demand on code, so a demo that works may still fail on the other three.
- A first slice is a minimal, functional, demonstrable version of a project that runs through the important parts of the system at a small scale.
- Deferring testing, review, deployment, or maintenance concerns is a common pitfall that shows up after a demo succeeds, so these concerns should be designed for from the start.