Software Development Lifecycle Part 2

Software development rarely follows a straight line. The actual work is full of uncertainty, shifting requirements, and competing priorities. The trap is thinking you can just start coding and figure things out as you go — what engineers call "hacking." The actual job is to impose enough structure to avoid chaos without crushing creativity or speed.

This lesson gives you a grounded overview of common software development lifecycle (SDLC) models, their strengths and weaknesses, and how to pick the right one for your project. You will also learn why no single model fits all situations, and how hybrids or adaptations are often necessary.

Code-and-Fix is chaos masquerading as progress

The simplest model is the code-and-fix approach. It starts with an informal idea and proceeds by writing code until the product is "ready" or resources run out. There is no plan or order — work happens in random bursts.

Advantages of code-and-fix:

• No administrative overhead. No meetings or documentation slow you down.
• Early signs of progress — you can show working code quickly.
• Low expertise needed. Anyone can start coding.
• Useful for small proof-of-concept projects or risk reduction experiments.

Limitations of code-and-fix:

• Dangerous for anything beyond tiny projects.
• No visibility or control over progress.
• No resource or time planning.
• No deadlines, so projects can drag or stall.
• Mistakes are hard to detect or correct until very late.
• Impossible to scale for large projects — communication breakdown and chaos reign.

This is exactly what Talvinder calls "hacking." It works only when urgency trumps everything else — for example, a solo developer testing an idea or a quick risk experiment within a larger project. If you try this for a serious product, you will pay in rework, delays, and unhappy customers.

The waterfall model is idealized and often unrealistic

The waterfall model is a classic approach with distinct, sequential phases: requirements, design, implementation, testing, and deployment. You finish one phase completely before moving to the next.

Advantages:

• Clear structure and documentation.
• Easy to understand and manage for teams used to formal processes.
• Works well when requirements are stable and well understood.

Limitations:

• Unrealistic to expect accurate requirements early in the project.
• Does not reflect the iterative nature of exploratory development.
• Software is delivered late, delaying discovery of serious errors.
• Difficult to integrate risk management.
• Expensive and complicated to make changes once documents are baselined — "swimming upstream."
• High administrative overhead, costly for small teams and projects.

Talvinder points out that waterfall often fails because it assumes perfect knowledge upfront. In reality, especially in Indian startup contexts, requirements evolve rapidly. Waiting until the end to test means costly surprises.

Iterative models embrace experimentation and risk management

Because end-user requirements are hard to obtain and define precisely, experimental development is natural:

1. Build some software.
2. See if it meets customer requirements.
3. If not, repeat.

This loop gave rise to structured iterative lifecycle models.

The Spiral Model

Barry Boehm developed the spiral model in 1988 to combine iteration with risk analysis and management.

Key idea: On each iteration, identify and solve the sub-problems with the highest risk.

Each cycle follows a mini-waterfall:

• Determine objectives
• Specify constraints
• Generate alternatives
• Identify risks
• Resolve risks
• Develop next-level product
• Plan next cycle

Benefits of the spiral model:

• Realistic: reflects the iterative nature of software development on projects with unclear requirements.
• Flexible: incorporates advantages of waterfall and rapid prototyping.
• Comprehensive: decreases risk and improves project visibility.

Limitations:

• Requires technical expertise in risk analysis to be effective.
• Poorly understood by non-technical management, limiting adoption.
• Complex; demands competent professional management.
• High administrative overhead.

The spiral model is powerful for large, complex projects where risk management is critical — for example, enterprise software with many unknowns. But it is less common in startups due to its complexity.

Rapid Prototyping focuses on customer collaboration and validation

Rapid prototyping emphasizes requirements analysis and validation through building early, visible prototypes. Also called customer-oriented or evolutionary prototyping.

Key idea: Customers are often non-technical and don't know exactly what they want or can have.

Benefits:

• Reduces risk of incorrect user requirements.
• Good for projects where requirements are changing or uncommitted.
• Regular visible progress aids management and builds stakeholder confidence.
• Supports early product marketing and user buy-in.

Limitations:

• An unstable or poorly implemented prototype can become the final product by default.
• Requires extensive customer collaboration and commitment.
• Costs customers time and money.
• Difficult to finish if customers withdraw.
• May be too customer-specific, limiting broader market appeal.
• Hard to estimate project duration.
• Easy to fall back into code-and-fix without proper requirements analysis, design, and feedback.

Rapid prototyping works well in Indian startups where customer needs evolve and early feedback is vital. Meesho's success, for example, relied on rapid iteration with sellers and buyers.

Visualizing workflow and managing work-in-progress improves flow

Managing work-in-progress (WIP) is critical to balancing speed with quality. When teams start too many tasks simultaneously, progress slows and thrashing increases.

Visualizing the workflow — the sequence of tasks and their dependencies — helps teams see bottlenecks and adjust priorities. Pull-based models like Kanban limit WIP by only starting new work when capacity is free.

As Talvinder notes, when something finishes, the next highest priority item from the backlog is pulled into play. This flow-based approach enhances delivery and prevents overload.

For teams transitioning from Scrum to more flow-oriented methods, the Scrumban hybrid is popular. It combines Scrum’s sprint structure with Kanban’s continuous pull model.

Learn more about Scrumban

Choosing the right SDLC model depends on your context

There is no silver bullet. The right lifecycle model depends on:

• Project size and complexity
• Clarity and stability of requirements
• Team experience and skills
• Criticality of the product (e.g., safety-critical vs. consumer app)
• Time-to-market pressures
• Organizational culture and stakeholder expectations

Talvinder’s pattern is consistent: figure out which or what tweak of an existing SDLC model will work best for your product, team, and market.

Many products evolve through multiple SDLC models as they mature. For example, early-stage startups may start with rapid prototyping or code-and-fix to test ideas, then move to iterative or waterfall approaches for scaling and stability.

Large projects often combine models — for instance, using waterfall for core platform components and agile for user-facing features.

The PM’s role in managing SDLC

The product manager’s job is not to dictate the engineering process but to understand the trade-offs and constraints of the chosen SDLC model. This enables:

• Setting realistic expectations with stakeholders.
• Identifying risks early and planning mitigation.
• Ensuring continuous customer feedback loops.
• Balancing speed, quality, and cost.
• Communicating progress and blockers clearly.

Talvinder emphasizes that most PMs confuse process with progress. A process without progress is bureaucracy. Progress without process is chaos. The goal is to find the balance that delivers customer value predictably.

Test yourself: Selecting an SDLC model for a fintech product

Where to go next

• If you want to master Agile and Scrum frameworks: Agile Fundamentals and Scrum
• If you want to improve your risk management skills: Managing Product Risks
• If you want to deepen your customer validation techniques: User Research Methods
• If you want to learn about product delivery metrics: Metrics and KPIs
• If you want to understand product lifecycle stages: Product Lifecycle Management

PL alumni now work at Razorpay, Swiggy, Flipkart, PhonePe, Meesho, and other leading Indian tech companies.