Next-Gen App & Browser Testing Cloud

Trusted by 2 Mn+ QAs & Devs to accelerate their release cycles

Which Step of SDLC Is Where Programming Is Done?

Q: In which phase of the SDLC is programming done?

Programming is done in the Implementation phase of the SDLC, also called the Coding or Development phase. It is the fourth stage in the classic model, coming after Requirement Analysis, Planning, and Design, and before the Testing phase.

Programming, or the actual writing of software code, is done in the Implementation phase of the Software Development Life Cycle (SDLC) — also known as the Coding phase or Development phase. This stage comes after the Design phase and before the Testing phase. During implementation, developers translate the approved design documents and the Software Requirements Specification (SRS) into working source code using a programming language, an IDE, and supporting tools such as compilers, debuggers, and version control.

Below, we walk through every SDLC phase, zoom in on what really happens during coding, explain exactly where implementation fits, and cover the best practices, model differences, and common mistakes that separate clean code from costly rework.

Overview of SDLC Phases

The Software Development Life Cycle is a structured framework that breaks software creation into a sequence of well-defined phases. Each phase has its own goal, its own owners, and its own deliverables that feed into the next stage. While different organizations name and group these phases slightly differently, the classic model has six to seven steps. Coding is just one of them — and knowing exactly where it sits helps you understand what must already be finished before a single line of code is written.

Here is how the standard SDLC phases line up, and where programming happens:

1. Requirement Analysis: primary goal is to gather and document what the software must do; key output is the SRS document.
2. Planning: primary goal is to estimate cost, scope, schedule, and resources; key output is the project plan.
3. Design: primary goal is to define architecture, data models, and UI; key output is the design document (HLD/LLD).
4. Implementation (Coding): primary goal is to write the actual source code; key output is working source code.
5. Testing: primary goal is to verify the software meets requirements; key output is test reports and bug fixes.
6. Deployment: primary goal is to release the software to production; key output is the live application.
7. Maintenance: primary goal is to fix issues and add enhancements over time; key output is patches and updates.

As the list makes clear, programming sits squarely in phase 4, Implementation. Everything before it is about deciding what to build and how to build it; everything after it is about proving the code works and getting it into users' hands. For a deeper walkthrough of each step, see our guide on the stages of the software development life cycle, or the complete software development life cycle (SDLC) guide.

You will sometimes see the SDLC described as having five phases rather than six or seven — that simply groups the same work differently. Requirement Analysis and Planning are often merged into one Planning stage, and Deployment and Maintenance are folded together, but the coding step is never removed: Implementation is a phase in every version of the model, whether it is drawn with five stages or seven.

The Implementation (Coding) Phase Explained

The Implementation phase is where ideas finally become a working product. It is often the longest and most resource-intensive stage of the SDLC, because this is where the team converts every diagram, wireframe, and requirement into executable software. Let us break down the essentials.

What Happens During Coding

Developers build the application module by module, writing functions, classes, and components that implement the behavior defined in the design. They translate concrete design artifacts — flowcharts, UML diagrams, pseudocode, and the low-level design document — into real statements in the chosen language, working component by component. They integrate with databases and third-party services, wire up APIs, and assemble the user interface. As modules are completed, they are committed to a shared repository so the whole team works from a single source of truth.

Who Does the Coding

Software developers and programmers are the primary owners of this phase. Depending on the project, that may include front-end developers, back-end developers, full-stack engineers, and mobile developers. They are usually supported by technical leads who review code and DevOps engineers who maintain the build pipeline. To understand how these responsibilities split up, see the different types of software engineer roles.

Inputs and Outputs

Inputs: the approved design document (high-level and low-level design), the SRS, coding standards, and the chosen tech stack.
Outputs: working source code in version control, unit tests, build artifacts, and inline code documentation that feeds straight into the Testing phase.

A typical module starts as a small, well-scoped piece of code. Here is a tiny illustrative example of what a developer might write during implementation:

// Implementation phase: turning a design rule into code
public class DiscountCalculator {

    // Design said: orders over 100 get a 10% discount
    public double applyDiscount(double orderTotal) {
        if (orderTotal > 100) {
            return orderTotal * 0.90;
        }
        return orderTotal;
    }
}

Where Implementation Fits in the SDLC

Implementation always sits after Design and before Testing, and that ordering is deliberate. Coding before design is finished leads to rework, because developers end up building features that do not match the architecture or the requirements. Coding before testing is correct, because you cannot test software that does not yet exist.

What comes before: the Design phase hands over architecture diagrams, data models, and detailed specs. Coding cannot responsibly begin until these are stable.
What comes after: the Testing phase receives the compiled, working code and verifies it against the SRS. Bugs found here are sent back to developers for fixes.

It is worth noting that developers do not skip testing entirely during implementation. They write unit tests for their own modules as they go, which is different from the formal, system-wide testing that the dedicated QA phase performs. To see how those layers connect, read about integration testing in software testing.

Best Practices in the Coding Phase

Writing code that compiles is easy; writing code that is maintainable, reviewable, and reliable is the real goal of a healthy implementation phase. These practices keep the coding stage productive and prevent technical debt from piling up:

Follow coding standards. Consistent naming, formatting, and structure make code readable for the whole team and easier to maintain long after the original author moves on.
Use version control. Tools like Git let developers branch, merge, and roll back safely. Small, frequent commits with clear messages create a traceable history.
Hold code reviews. A second pair of eyes catches bugs, security issues, and design drift before code is merged. Peer review is one of the cheapest quality controls available.
Write unit tests. Test individual functions and classes as you build them so regressions surface immediately rather than weeks later in QA.
Keep modules small and decoupled. Single-responsibility functions are easier to test, debug, and reuse than sprawling, tightly coupled code.
Document as you code. Clear inline comments and API docs save the next developer hours of reverse-engineering.

How Coding Differs Across SDLC Models

The coding phase always exists, but when and how it happens changes dramatically depending on the development model. The biggest difference is whether coding is one big block or a continuous, repeating activity. For a broader comparison, see the most popular types of SDLC models.

Waterfall: coding happens in one sequential block, after all design is signed off; testing is a distinct phase that follows coding.
Agile: coding is repeated every sprint, in small increments; coding and testing overlap within each iteration.
DevOps: coding is continuous, integrated with CI/CD pipelines; automated tests run on every commit.

In Waterfall, the coding phase is a clearly bounded stage with a firm start and end. In Agile, coding repeats every sprint, with a little design, a little code, and a little testing in each cycle. In DevOps, coding becomes continuous: developers commit small changes that flow through automated build, test, and deployment pipelines many times a day. For practical guidance on this continuous model, see our overview of DevOps best practices.

Common Mistakes and Troubleshooting

Starting to code before design is stable. Jumping in early feels productive, but it usually means rebuilding modules when the architecture changes. Wait for a stable design baseline.
Skipping code reviews. Merging unreviewed code lets bugs and inconsistent patterns slip into the codebase, where they are far more expensive to fix later.
Ignoring coding standards. A codebase where every developer formats and names things differently quickly becomes unreadable and hard to maintain.
Treating testing as someone else's job. Developers who never write unit tests push fragile code into QA, slowing the whole pipeline. Test as you build.
Committing huge, infrequent changes. Large commits are hard to review and hard to roll back. Commit small and often with descriptive messages.

Conclusion

So, which step of the SDLC is where programming is done? The answer is the Implementation phase — the Coding or Development stage that sits after Design and before Testing. It is where developers convert design documents and the SRS into working source code, guided by coding standards, version control, code reviews, and unit tests. Whether your team works in Waterfall, Agile, or DevOps, the coding phase is the moment the product becomes real. Follow solid practices during implementation to turn that code into software you can ship with confidence.

Frequently Asked Questions

In which phase of the SDLC is programming done?

Programming is done in the Implementation phase, also called the Coding or Development phase. It is the fourth stage in the classic model, coming after Requirement Analysis, Planning, and Design, and before the Testing phase.

What is the difference between the design phase and the coding phase?

The design phase produces blueprints such as architecture diagrams, data models, and the design document, while the coding phase translates those blueprints into actual source code in a programming language. Design decides how, coding builds it.

Who is responsible for coding in the SDLC?

Software developers and programmers write the code during the Implementation phase. They work from design documents and the SRS, follow coding standards, use version control, and often write unit tests for the modules they build before handing off to QA.

Is testing part of the coding phase in the SDLC?

Formal system testing is a separate phase that follows coding, but developers do write unit tests during implementation. In Agile and DevOps, coding and testing overlap heavily, with automated tests running continuously alongside development.

What are the outputs of the implementation phase?

The main output of the implementation phase is working source code committed to version control, along with unit tests, build artifacts, and code documentation. This code becomes the input for the Testing phase that follows.

What are the 7 stages of the SDLC?

The seven stages are Requirement Analysis, Planning, Design, Implementation (Coding), Testing, Deployment, and Maintenance. Programming happens in the fourth stage, Implementation. Some organizations compress these into five phases by merging Analysis with Planning and Deployment with Maintenance, but coding remains its own dedicated step.

What phase comes after coding in the SDLC?

The Testing phase comes right after coding. Once developers finish and commit working source code, QA verifies it against the SRS through functional, integration, and system testing. Bugs found there are sent back to developers to fix before the software moves on to Deployment.