Software Development Lifecycle Part 2

Software development is rarely straightforward. The process you pick to build your product shapes everything from timeline to quality to team morale. The trap is to treat software development as a single, fixed process — it is not. You must choose and adapt the right lifecycle model for your project’s complexity, uncertainty, and constraints.

This lesson walks through the major software development lifecycle (SDLC) models, their trade-offs, and how to think about picking the right one for your product context.

The code-and-fix model is chaos disguised as progress

The code-and-fix approach starts with a vague product idea and just builds code until the product is “ready” or money runs out. There is no plan, no schedule, no deadlines — just hacking.

It has some advantages:

• No administrative overhead or documentation needed
• Early signs of progress — you see code quickly
• Low expertise required — anyone can start coding
• Useful for small proofs-of-concept or experiments to reduce risk

But the limitations make it dangerous for serious projects:

• There is no visibility or control over progress
• No resource planning or deadlines leads to chaos
• Mistakes are hard to detect or correct early
• Communication breaks down as the project scales
• Impossible to manage large projects with this approach

This is what I call the “wild west” of software development. It may feel productive at first but almost always leads to missed deadlines, poor quality, and burnout.

The waterfall model is a rigid ideal that rarely fits reality

Waterfall is the classic, linear approach where requirements are fully specified upfront, then design, development, testing, and deployment happen sequentially.

It has strengths in projects where requirements are very clear and unlikely to change:

• Strong project management and documentation
• Predictable timelines and milestones
• Good for regulatory or safety-critical systems where traceability is essential

But waterfall struggles in real-world product development:

• It assumes accurate requirements can be defined early — often unrealistic
• Software is delivered late, delaying discovery of serious errors
• Changes are costly and difficult to incorporate (“swimming upstream”)
• Risk management is hard to integrate
• High administrative overhead, especially for small teams or startups

Most product teams find waterfall too slow and inflexible to keep up with evolving user needs.

The spiral model embraces risk and iteration explicitly

Developed by Boehm in 1988, the spiral model combines iterative development with risk analysis and management. It is especially suited when user requirements are unclear or changing.

Each cycle of the spiral includes:

1. Determine objectives and constraints
2. Identify and resolve risks
3. Develop and test deliverables
4. Plan the next iteration

Progress moves outward in a spiral, with cumulative cost increasing but risk decreasing as uncertainties are addressed early.

Benefits include:

• Realistic reflection of software development’s iterative nature
• Flexible, incorporating waterfall and prototyping advantages
• Comprehensive risk management reduces project failure
• Good project visibility and early problem detection
• Accommodates changing requirements and priorities

Limitations are:

• Requires technical expertise in risk analysis to execute well
• Complex and hard to explain to non-technical stakeholders
• High administrative overhead and management effort
• Frequent changes can be challenging for teams without discipline

The spiral model is a good fit for large, complex projects with high uncertainty and risk.

Staged delivery blends waterfall with incremental releases

The staged delivery model starts with waterfall-like phases: concept, requirements analysis, architectural design. Then it breaks development into multiple stages, each delivering a working product increment.

This approach allows:

• Delivery at the end of each cycle, showing progress and satisfying customers
• Early visibility of integration and quality problems
• Shorter, more predictable release cycles
• Flexibility to adjust scope between stages

Limitations include:

• Requires tight coordination across documentation, management, and marketing
• Product must be decomposable into meaningful increments
• Extra releases add overhead

Staged delivery is practical and widely used, especially in enterprise environments.

Evolutionary prototyping puts customer feedback first

Evolutionary prototyping builds a skeleton system and evolves it based on continuous customer evaluation and feedback.

The workflow:

• Capture initial requirements
• Quickly design and build a prototype
• Get customer feedback and iterate on design
• Engineer the final product once validated

Benefits:

• Reduces risk of building the wrong thing by involving customers early
• Supports changing or uncommitted requirements
• Shows regular progress to management and marketing
• Builds customer confidence through involvement

Limitations:

• Requires committed customers willing to collaborate closely
• Customers may not know what they want initially, causing scope creep
• Planning is difficult; estimating timelines and features is hard
• Risk of prototypes becoming final products without sufficient polish
• Customer withdrawal can jeopardize completion
• May result in overly customized products with limited market appeal

Evolutionary prototyping suits products with uncertain requirements and a need for rapid feedback.

Agile and Extreme Programming focus on people and adaptability

Agile methodologies like Extreme Programming (XP) emphasize:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a fixed plan

XP practices include:

• Continuous delivery and planning
• Pair programming and test-driven development
• Shared code ownership and coding standards
• Maintaining simplicity and continuous feedback

Benefits:

• Lightweight and iterative, suitable for small to mid-size teams
• Produces good team cohesion and focuses on delivering value
• Emphasizes quality through testing and collaboration

Limitations:

• Hard to scale to large projects requiring extensive documentation
• Needs experienced teams to avoid degenerating into code-and-fix
• Pair programming and test case development can be costly and require skill

Agile is now the dominant approach in product companies that value adaptability.

Kanban visualizes workflow to optimize flow and limit work in progress

Originating at Toyota, Kanban manages work by visualizing tasks and controlling the number of items in progress.

Principles:

• Visualize current work: seeing all tasks in context improves understanding
• Limit work in progress (WIP): prevents overloading teams and improves focus
• Enhance flow: when a task finishes, pull the next highest priority item from the backlog

Benefits:

• Lightweight and easy to adopt
• Improves team cohesion and responsiveness
• Supports continuous delivery and rapid feedback loops

Limitations:

• Communication can be challenging when multiple people work on the same item
• No defined delivery times or sprints
• Less flexible for frequent priority changes or product mix shifts

Kanban works well for operational environments with stable priorities and continuous delivery needs.

Comparing SDLC models helps you pick the right fit

Here is a comparison of common SDLC models by key factors:

The choice of SDLC model depends on your project context

No single model is best for every project. Instead, consider:

• The clarity of user requirements
• The complexity and criticality of the system
• The level of risk and uncertainty
• The size and experience of your team
• The need for visibility and stakeholder involvement
• Time to market and cost constraints

Often, teams combine models or evolve their approach as the product matures — for example, starting with rapid prototyping to explore ideas, then moving to staged delivery or agile for scaling.

Here is what I tell PMs: Aim for good, fast, and cheap — but you cannot have all three at the same time. Prioritize based on your project’s biggest risks and constraints.

How epics, stories, and tasks fit into SDLC

In agile and iterative models, work is broken down hierarchically:

• Theme: A broad objective or area of focus (e.g., "Wishlist feature")
• Epic: A large body of work that can be broken into smaller pieces (e.g., "Add wishlist functionality to app")
• User story: A specific feature or requirement from the user’s perspective (e.g., "As a user, I want to add items to my wishlist")
• Task: The smallest unit of work to be done by developers (e.g., "Implement the add-to-wishlist button")

This breakdown helps teams plan, prioritize, and deliver value incrementally.

Test yourself: Choosing the right SDLC model

From the field: Why iterative delivery won at Razorpay

When I worked with Razorpay’s early product team, they started with a waterfall plan but quickly realized their market and customer needs were shifting fast. They switched to an iterative prototyping approach — building a minimal core payments engine, releasing it internally, and learning from early users.

This allowed them to discover critical compliance and integration requirements early, which would have caused costly rework in waterfall. Their ability to pivot every 2 weeks kept the product relevant and accelerated time to market.

This is what week one looks like for most new PMs. Everyone needs something from you. All of it feels urgent. None of it tells you what your actual job is.

Your actual job is this: figure out which of these things matters most for the customer, and make a call. Not answer all of them. Not please everyone. Make a call.

Where to go next

• If you want to master agile planning and execution: Agile Fundamentals and Scrum
• If you want to learn how to break down work into epics and user stories: Epics, Stories, and Tasks
• If you want to understand how to manage product backlogs and prioritize: Backlog Management and Prioritization
• If you want to improve your stakeholder communication and reporting: Product Reporting and Stakeholder Management
• If you want to learn from real Indian startup product teams: From the Field: Indian Product Stories