The Software Development Lifecycle

"Suppose one of you wants to build a tower. Won't you first sit down and estimate the cost to see whether you have enough money to complete it? For if you lay the foundation and are not able to finish it, everyone who sees it will ridicule you, saying, 'This person began to build and wasn't able to finish.'" — Luke 14:28-30

Count the Cost Before You Build

Jesus told this parable to teach a spiritual lesson about the cost of discipleship, but the earthly wisdom in it is striking: before you build anything, plan first. Count the cost. Understand what you need. Anticipate problems. Only a fool begins construction without a blueprint.

Software engineering applies this exact principle through the Software Development Lifecycle (SDLC) — a structured process that guides a project from initial idea to finished product and beyond. The SDLC is not a single rigid formula; it is a framework that helps teams avoid the chaos of building without a plan.

The Six Phases of the SDLC

Phase 1: Requirements Gathering

Before writing a single line of code, you must understand what needs to be built and why. Requirements gathering means talking to the people who will use the software (stakeholders), understanding their problems, and documenting exactly what the software must do.

"Prepare your work outside; get everything ready for yourself in the field, and after that build your house." — Proverbs 24:27

Key activities in this phase:

• Interviews with users and stakeholders
• User stories: short descriptions of features from the user's perspective (e.g., "As a student, I want to track my reading progress so I can see how much I have learned")
• Acceptance criteria: specific, measurable conditions that define when a feature is "done"
• Feasibility analysis: Can this actually be built with the available time, budget, and skills?

A requirement that is vague ("make it fast") is not a requirement. Good requirements are specific ("the page must load in under 2 seconds"), measurable (you can test it), and achievable (it is technically possible).

Phase 2: System Design

Once you know what to build, you plan how to build it. Design is the blueprint phase. Architects do not start pouring concrete before drawing plans — engineers do not start coding before designing the system.

Key design decisions include:

• Architecture: How will the major pieces of the system be organized? Will it be a monolith (one large application) or microservices (many small, independent services)?
• Data model: What data will the system store? How will it be structured? What are the relationships between data entities?
• API design: How will different parts of the system communicate with each other?
• Technology choices: What programming language, framework, database, and hosting platform will be used?
• User interface (UI) design: What will the user see and interact with? Wireframes and mockups are created.

Good design documents are living blueprints that the team references throughout development.

Phase 3: Implementation (Coding)

This is the phase most people think of when they hear "software development" — actually writing the code. But notice it is Phase 3, not Phase 1. By the time you start writing code, you should already know what you are building (requirements) and how it will be structured (design).

Implementation best practices include:

• Follow coding standards: consistent naming conventions, indentation, and file organization
• Write small, focused functions: each function should do one thing well
• Use version control: commit your work frequently with clear messages (we will cover Git in Day 4)
• Document as you go: write comments explaining why, not just what
• Pair programming: two engineers working together catch more bugs and produce better designs

Phase 4: Testing

"Test all things; hold fast to what is good." — 1 Thessalonians 5:21

Testing verifies that the software works correctly. Professional software engineers do not simply run the program once and declare it finished. They write automated tests — code that tests other code — so that every change can be verified quickly and reliably.

Types of testing:

• Unit tests: Test individual functions or components in isolation. "Does this function correctly calculate a total?"
• Integration tests: Test that different parts of the system work together. "Does the payment system correctly communicate with the database?"
• End-to-end (E2E) tests: Test the entire application from the user's perspective. "Can a user sign up, log in, and complete a purchase?"
• Regression tests: Re-run previous tests to ensure new changes did not break existing functionality.

Bun includes a built-in test runner (`bun test`) that we will use extensively in this course.

Phase 5: Deployment

Deployment is the process of making the software available to users. For a web application, this means uploading it to servers where people can access it through their browsers. For a mobile app, it means publishing to an app store.

Modern deployment practices include:

• Continuous Integration/Continuous Deployment (CI/CD): automated pipelines that test and deploy code every time changes are made
• Staging environments: a copy of the production system where changes are tested before going live
• Rollback plans: the ability to quickly revert to a previous version if something goes wrong
• Monitoring: watching the live system for errors, slow performance, or unusual activity

Phase 6: Maintenance

Software is never truly "finished." After deployment, bugs are discovered, user needs change, security vulnerabilities are found, and new features are requested. Maintenance is often the longest phase — a successful application may be maintained for decades.

Maintenance activities include:

• Bug fixes: correcting defects discovered after release
• Security patches: closing vulnerabilities
• Performance optimization: making the system faster or more efficient
• Feature additions: building new capabilities users request
• Technical debt repayment: improving code quality and architecture over time

Waterfall vs. Agile

The six phases above can be followed in different orders and rhythms. Two major approaches dominate the industry:

Waterfall follows the phases sequentially — finish requirements completely before starting design, finish design completely before starting coding, and so on. It is predictable and well-documented, but inflexible. If requirements change mid-project (and they almost always do), Waterfall struggles.

Agile moves through all six phases in short cycles called sprints (typically 1-2 weeks). Each sprint delivers a small, working piece of the software. Requirements, design, coding, testing, and deployment happen in every sprint. Agile embraces change and delivers value incrementally.

| Aspect | Waterfall | Agile | |--------|-----------|-------| | Phases | Sequential | Iterative (repeated in sprints) | | Planning | All upfront | Continuous | | Delivery | One big release at the end | Small releases every sprint | | Change | Difficult and expensive | Expected and welcomed | | Documentation | Extensive upfront docs | Living docs, updated continuously | | Best for | Fixed requirements, regulatory | Evolving requirements, innovation |

Most modern software teams use some form of Agile, but the underlying SDLC phases remain the same regardless of methodology.

A Thought to Carry

Whether building a tower (Luke 14:28) or a software system, the principle is the same: count the cost, make a plan, and build with discipline. The SDLC is not bureaucratic overhead — it is the engineering wisdom that prevents half-built towers and unmaintainable code.