There are many situations in software development where a single software developer is in charge of building or maintaining an application. How do you do code review in this case? In this article Niral Dhameliya suggests that a senior developer perform the release review process with a checklist can be finished in under an hour.
Author: Niral Dhameliya, Partner and the CTO of Empiric Infotech LLP, https://empiricinfotech.com
Many software products are built by very small teams. A startup hires one developer for its first app, a company extends its team with a single remote engineer, or a product moves into maintenance with one person doing most of the work. In each case, the usual safety net of a large team is missing: there is no second developer reading every change and no dedicated tester running every build.
The fix is not to hire a full QA team. It is to put a second, senior pair of eyes on every release, and to make that review fast enough that nobody is tempted to skip it. This article describes a release review that a team lead can run in under an hour, the checklist behind it, and the habits that keep it practical.
Why the developer’s own testing is not enough
A developer who wrote a feature tests it the way they imagined it being used. That covers the happy path and the cases they thought of while coding. It rarely covers the cases they didn’t think of, because those are, by definition, outside their picture of the feature.
A reviewer arrives without that picture. They read the change as a user, and as the person who will maintain the code next year. In our experience, most of the problems a release review catches fall into a few groups: an empty or error state nobody designed, an input the code never expected, a change that quietly breaks an older screen, and a setting that works in the developer’s environment but not in production.
Keep releases small enough to review
A review only works if the reviewer can hold the whole change in their head. A release with three weeks of work in it can’t be reviewed properly in an hour, so it gets skimmed, and skimming finds little.
The DORA research program lists working in small batches as one of the capabilities that drive software delivery performance, and its guidance encourages developers to check in small, releasable changes at least once a day. For a one-developer team, a practical target is a release every week or two, each one small enough to describe in a few sentences.
If a release can’t be summarized in five bullet points, it is probably too big to review well. Split it.
The release review checklist
The reviewer works through the same list on every release. A fixed list matters more than a long one: the same questions, asked every time, catch the same kinds of mistakes before users do.
1. Read the summary before the code
The developer writes a short release note: what changed, why, and what might be affected. The reviewer reads it first and checks that the change matches the request. Many problems are found here, before any code is opened, simply because the change solves a slightly different problem from the one that was asked.
2. Review the design of the change, not only the lines
Google’s public code review guide puts design first: do the pieces of the change make sense together, does the change belong in this part of the codebase, and does it fit the rest of the system? For a small team, the most common design problem is a quick fix in the wrong place, such as a business rule copied into a screen instead of being kept in one shared function.
3. Run the feature as a new user and as an old one
The reviewer uses the feature twice: once with a fresh account and no data, and once with an account that has a long history. Empty states, first-run screens and migrations from older data behave very differently, and the developer usually tested only one of them.
4. Try the inputs nobody planned for
Long names, empty fields, pasted text with line breaks, very large numbers, a slow connection, and a second tap on a button that is still loading. Five minutes of deliberate misuse often finds more than an hour of normal clicking.
5. Check what the change could break elsewhere
The reviewer asks which other screens use the code that changed, and opens them. In small codebases, shared components are reused heavily, so a fix in one place can easily break layout or behavior in another.
6. Check the tests that came with the change
The same Google guide recommends that tests arrive with the code they cover, and that the reviewer checks those tests are correct and useful, since tests don’t test themselves. For a small team, the minimum is one test for the main rule the change introduces, and one for the bug it fixes, if it fixes one.
7. Compare environments
Configuration differences between staging and production are a common cause of release-day surprises. The reviewer checks new environment variables, third-party keys, feature flags and database changes, and confirms each one exists where the release is going.
8. Decide, and write it down
The review ends with one of three outcomes: release, release with a follow-up ticket, or hold. A one-line note with the outcome and the reason builds a simple history that is useful when something goes wrong months later.
Making it stick
The checklist above takes 30 to 60 minutes for a typical small release. Three habits keep it from being skipped:
- Schedule it. Put a fixed review slot in the calendar for every release day, so the review does not compete with other work.
- Give the reviewer authority to hold a release. A review that can’t stop anything quickly becomes a formality.
- Share what the reviews find. A monthly look at the issues caught in review shows the developer where their blind spots are, and the same mistakes start to disappear from future releases.
When there is no team lead
If the developer works alone for a client, the client can still run a lighter version: read the release note, use the feature as a new user and as an existing one, and try a few unexpected inputs. That alone catches many of the issues a full review would, and it gives the client a clear view of what they are paying for.
One developer can ship good software. The difference between a fragile product and a solid one is often a second pair of eyes, applied every time, with a checklist that does not change.
References
- Google Engineering Practices, “What to look for in a code review”: https://google.github.io/eng-practices/review/reviewer/looking-for.html
- DORA, “Capabilities: Working in small batches”: https://dora.dev/capabilities/working-in-small-batches/
About the Author
Niral Dhameliya is a Partner and the CTO of Empiric Infotech LLP, a custom software development company founded in 2020. He leads engineering teams that build web and mobile products in Flutter, React, Node.js and Python for clients in more than 25 countries, and he writes about practical ways to keep small development teams shipping reliable software.
Leave a Reply