How a feature travels from idea to production

Written Explanation

The path in one picture

Idea -> Requirements -> Design -> Code -> Review -> Test -> Release -> Monitor
  ^                                                                      |
  +----------------- feedback, bugs, new ideas --------------------------+

We will follow one feature through all eight stations: "show the estimated delivery time on the order confirmation" for a food-ordering backend.

Station 1: Idea

A feature starts with a need. It might come from a customer ("I never know when the food will arrive"), from support ("we get fifty messages a day asking where the order is"), from the business ("late deliveries lose us customers"), or from the team ("our notifications are confusing").

At this station, nobody has written anything yet. The goal is to decide whether the idea is worth pursuing. A good idea is stated as a problem: "customers do not know when their food will arrive". A bad one is stated as a solution too early: "add a clock widget". The previous lesson's habit applies: ask what problem we are solving.

Station 2: Requirements

Requirements say what the feature must do, clearly enough that everyone, including people who will test it, can agree whether it works. You met this stage in the lifecycle lesson.

For our example, requirements could be:

• The order confirmation shows an estimated delivery time, in minutes, for the customer's address.
• The estimate must be a whole number of minutes between 15 and 90. (If the real calculation is outside that range, show the nearest limit.)
• If the restaurant is closed, the order is refused with a clear message instead of an estimate.
• The estimate must appear within one second of confirming the order.

Notice each line can be checked: either the screen shows the number or it does not. Vague requirements like "make delivery times better" cannot be tested. A requirement is also a chance to ask questions: what happens when the courier is late? Does the customer see the estimate again later? Every question answered now saves a change later.

People involved: someone who owns the product (often called a product manager or product owner), engineers, and sometimes support staff or designers.

Station 3: Design

Design answers: how will it work? Before writing code, the team decides on the main parts of the change. For our feature:

• Which service calculates the estimate? (The backend, because it knows the courier availability.)
• What information does the calculation need? (The restaurant's cooking time, the distance, and the current number of waiting orders.)
• What does the frontend ask for, and what does the backend answer? (Say, the request carries the order, and the response includes an estimate in minutes.)
• Where could it fail? (The courier system is slow or unavailable: do we show a default estimate or none?)

Design can be a ten-minute whiteboard talk for a small change or a written proposal for a large one. What matters is that the team agrees on the big decisions before writing code, because moving a box on a drawing is cheap and rewriting finished code is not. The architect or most experienced engineer often helps here, but any engineer can propose a design.

Station 4: Code

Now the engineer writes the code. In this lesson, that is not the longest station, even though many beginners think of it as the whole job.

A typical routine, described here briefly because it is taught in later modules:

1. The engineer works on the change in their own separate copy of the project, usually a branch in a version control system such as Git. A branch lets someone work on a change without disturbing teammates, who keep working on the main version.
2. The engineer writes the code for the feature, and also the tests that prove it works (see below).
3. They run the program and the tests on their own computer.

Code is written for the reader (lesson 1): clear names, small pieces, and a short comment where the reason is not obvious.

Station 5: Review

When the change is ready, the engineer asks teammates to look at it before it joins the main version. In many teams this is done with a pull request: a proposal to merge the changes into the project, which gives collaborators a place to discuss and review the change first. GitHub's documentation describes it in those terms: a pull request lets people review the proposed change and see automatic check results, and it shows whether anything blocks the merge, such as missing approvals.

A code review means a teammate reads the change and gives feedback. They might ask: Does it do what the requirements say? Is it understandable? Does it handle the unusual cases? Is it safe, for example with personal data? Does it fit the design?

Why do teammates review? Two main reasons:

• To catch mistakes early. A second pair of eyes sees what the author is blind to. A mistake found in review is cheaper than one found in production.
• To share knowledge. Reviewing teaches the reviewer about this part of the system, and the author learns better ways to do things. Afterwards, more than one person understands the code.

Reviews go best when feedback is about the code, not the person, and when the author reads comments as help. A review is a conversation: the author may explain, change, or politely disagree. When everyone is satisfied, the change is merged, which means it becomes part of the main version.

Station 6: Test

Testing happens throughout, but there is a distinct moment where the change is checked as a whole. Two types matter here:

• Automatic tests are small programs that check the software and report pass or fail. They run on a server whenever someone proposes or merges a change. This practice is called continuous integration (CI): changes are merged into the shared code frequently, and every merge triggers an automatic build and tests, so integration problems appear within minutes or hours instead of weeks.
• Manual checks by a QA engineer or by the team: trying the feature in a test environment like a real user would, and looking for odd cases.

A test environment is a separate copy of the application, with fake data, where the team can try changes safely. It prevents a bad change from touching real customers' orders.

For our feature, tests would cover: a normal estimate, an estimate below 15 (shown as 15), an estimate above 90 (shown as 90), a closed restaurant, and the courier system being unavailable.

If a test fails, the change goes back to the code station. This is not a failure of the team; it is the system doing its job. Finding the problem here costs minutes. Finding it after release costs much more.

Remember what testing cannot do: it can show that problems exist, but passing tests do not prove there are none. That is why the next two stations exist.

Station 7: Release

Release means putting the new version where real users can use it. For a backend, this means putting the new instructions onto the production servers and starting them, often called deploying. In many teams the release is carried out by an automatic pipeline (lesson 2): the same steps run every time, in the same order, without human typing mistakes.

Teams reduce the risk of a release in several ways:

• Small releases. Releasing one small change is easier to understand and to undo than releasing hundreds of changes at once. If something breaks, there are only a few suspects. Frequent integration and shorter release cycles are common themes in descriptions of DevOps practice, including Microsoft's.
• Careful rollout. Instead of switching everyone at once, a team may send the new version to a small share of users first, and widen it if all looks well. The SRE book describes progressive rollouts and fast, safe rollbacks as a way to limit damage.
• A way back. A rollback puts the previous version back quickly if the new one misbehaves.

The strict word choice does not matter yet. What matters is the idea: make the release step safe and boring.

Station 8: Monitor

After release, the work is not finished. The team monitors the feature: it watches signs that it is working. Monitoring typically includes:

• Errors: is the service returning failures?
• Speed: is the estimate still shown within one second?
• Behavior: are customers using the feature? Are support messages about delivery time falling?
• Feedback: what do users and support say?

In our example, the team notices that estimates for one district are always 15 minutes, because a missing distance defaults to zero. Support also reports that customers want to see the estimate again later. Both findings are new ideas and bugs: they re-enter the belt at the first station. The loop turns.

Monitoring is often shown on a dashboard (a screen of charts) and connected to alerts (automatic messages when something crosses a limit). Later modules show how to build this. For now, remember: shipping is not the end; watching is the last station and the first one of the next cycle.

Why small, frequent releases are safer

Compare two teams:

• Team A releases once every three months, with hundreds of changes at once. If the new version has a problem, nobody knows which of the hundreds of changes caused it. Fixing it takes days, and meanwhile users are affected.
• Team B releases every day or several times a day, with a few changes at a time. If there is a problem, the suspects are the few changes released today, and a rollback is simple.

The size of the change drives the risk. Smaller changes are easier to review, easier to test, easier to understand, and easier to undo. This is one reason teams invest in automatic tests and pipelines: they make frequent releases possible. I describe this as a general principle supported by the CI and DevOps literature; the exact release frequency that suits a team depends on the product and its risks.

Loops and shortcuts

Real work does not move in a straight line:

• A reviewer finds a design problem, so the change goes back to design.
• A test failure sends the code back for fixing.
• A monitor alert after release sends the team into an urgent fix, often with a faster review, but never with no checks at all.

Be suspicious of teams that skip stations to move faster. Skipping review or testing mostly moves the cost to production, where it is higher. What teams can do is make each station faster: smaller changes, automation, and clear requirements.