Software Development Lifecycle Part 2

Software development is not one-size-fits-all. The actual job is to pick a lifecycle model that fits your product’s complexity, your team’s expertise, and how well you understand user requirements. If you don’t, you’ll end up with chaos, wasted effort, or a product nobody wants.

Most Indian startups and enterprises struggle because they pick a lifecycle model without understanding its trade-offs. The result is late discovery of critical issues, cost overruns, and frustrated teams.

This lesson digs into the most common lifecycle models beyond the basics, focusing on their strengths, limitations, and when to use them. You’ll see how risk-driven and iterative models like Spiral and Rapid Prototyping address the reality of unclear requirements and evolving products.

The "Code and Fix" model is hacking, not development

The simplest approach is to start coding immediately with a vague product idea, keep building randomly, and stop only when the product is "ready" or you run out of time or money. This is often called "code and fix."

Advantages:

• No administrative overhead — you just start coding.
• Early signs of progress — you produce working code quickly.
• Low expertise required — anyone who can code can do it.
• Useful for small proof-of-concept projects or risk reduction experiments.

Limitations:

• Dangerous for anything beyond trivial projects.
• No visibility or control over progress or quality.
• No resource planning or deadlines.
• Mistakes are hard to detect and correct.
• Impossible to scale to large projects — communication breaks down into chaos.

This model corresponds to hacking, not disciplined software development. It works only for very small, low-risk efforts. If you try this on a complex product, you will fail.

The Waterfall model is idealised and rigid

Waterfall is the classic sequential model: requirements, design, implementation, testing, deployment, each phase completed before moving to the next.

Strengths:

• Clear structure and documentation.
• Easy to understand and manage for simple projects.
• Works well when requirements are well-known and stable.

Limitations:

• Unrealistic to expect accurate, complete requirements so early.
• Does not reflect the iterative, exploratory nature of most software development.
• Software is delivered late, delaying discovery of serious errors.
• Difficult to integrate risk management.
• Expensive and difficult to make changes once documents are baselined.
• High administrative overhead — costly for small teams or projects.

The Waterfall model works best for projects with fixed, well-understood requirements and low uncertainty. It is less suited for innovation or products where user needs evolve.

Iterative, risk-driven development is necessary when requirements are unclear

Because end-user requirements are often unclear or hard to define upfront, many teams adopt an experimental approach:

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

This loop gave rise to structured iterative lifecycle models.

One influential example is Boehm’s Spiral model (1988). It combines iterative development with risk analysis and management.

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

Each cycle roughly follows this sequence:

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

This approach aligns work with the riskiest unknowns first — whether technical, user-related, or business risks — reducing surprises later.

Benefits and challenges of the Spiral model

Benefits:

• Realistic: reflects the iterative nature of software development on projects with unclear requirements.
• Flexible: incorporates advantages of both Waterfall and rapid prototyping.
• Comprehensive: decreases risk by focusing on risk mitigation.
• Good project visibility through risk tracking.

Limitations:

• Requires technical expertise in risk analysis to implement effectively.
• Poorly understood by non-technical management, limiting adoption.
• Complex model needing competent professional management.
• High administrative overhead.

Because of these challenges, Spiral is less common in smaller companies or teams without dedicated project managers.

Rapid prototyping focuses on customer collaboration and requirements validation

Rapid prototyping, also known as evolutionary or customer-oriented development, acknowledges that customers are usually non-technical and often don’t know what they want or can have.

Key idea: Build a prototype early and evolve it based on frequent customer feedback.

Advantages:

• Reduces risk of incorrect user requirements.
• Well suited for projects where requirements are changing or uncommitted.
• Provides regular visible progress to management.
• Supports early product marketing by demonstrating working software.

Risks and limitations:

• An unstable or poorly implemented prototype can become the final product by accident.
• Requires extensive customer collaboration and commitment.
• Costs customers money and time.
• Difficult to finish if customer withdraws.
• May result in a product too specific to initial customers, limiting broader market appeal.
• Hard to estimate project duration.
• Easy to slip back into "code and fix" without proper requirements analysis, design, and feedback discipline.

Rapid prototyping works well in contexts where user needs are uncertain and the cost of building a throwaway prototype is low. It demands strong product management and disciplined customer engagement.

Visualising workflow with WIP helps balance flow and avoid overcommitment

Modern agile and lean teams use flow-based approaches to manage work in progress (WIP). Visualising all active tasks in context helps teams avoid starting too many things at once, which can cause delays and quality issues.

When a task finishes, the team pulls in the next highest priority item from the backlog. This pull system balances flow and reduces multitasking.

One popular approach combining flow and iteration is Scrumban, a hybrid of Scrum and Kanban.

For more, see:
What is Scrumban?

Matching SDLC models to project context is critical

No single SDLC model fits all products or teams. The actual job is to understand your product’s complexity, user requirement clarity, risk profile, and team capability — then pick or tailor a model accordingly.

Indian companies often start with ad hoc or Waterfall approaches and evolve toward iterative models as product complexity grows and teams mature.

Indian context: managing uncertainty and customer collaboration

In India, many startups build products where user requirements are not well defined upfront. Customers may be non-technical, and market needs can shift rapidly.

Rapid prototyping and iterative models help manage this uncertainty by enabling frequent customer feedback loops and risk mitigation.

At the same time, Indian product teams must balance administrative overhead and resource constraints. Overly complex models like Spiral may be impractical without the right expertise.

The best approach is pragmatic: start with prototypes to validate assumptions, then evolve into more structured iterations with clear risk management as the product scales.

Test yourself: Choosing the right SDLC model for a fintech startup

Where to go next

• If you want to understand how to gather and validate requirements effectively: User Research Methods
• If you want to learn agile ceremonies and workflows: Agile and Scrum Fundamentals
• If you want to build product roadmaps aligned to business goals: Product Roadmapping
• If you want to master risk management in product development: Risk Management for PMs
• If you want to practice iterative prototyping: Rapid Prototyping Techniques