Why do bugs happen, and why is software never finished?

Why do bugs happen, and why is software never finished?

Software is never finished because it never stops changing, and every change can break something. A physical product leaves the factory and stays the way it left. Software gets deployed and then keeps being edited, every day, by a team of people, while customers are using it. The previous lesson followed one change on its trip from a laptop to production. This lesson is about what happens after arrival: the change now lives in a running system, alongside every change that came before it, and the team is responsible for all of it at once.

That responsibility is a large share of an engineering team's actual week. A team that ships a feature also maintains the tests that protect it, carries a pager for the servers that run it, responds when it breaks, and periodically rebuilds its insides so the next feature is possible. A hiring manager who says the team is "mostly heads-down on reliability this quarter" is describing this half of the job. The words in this lesson, bug, test suite, on-call, incident, postmortem, technical debt, refactoring, are the vocabulary of that half.

What is a bug?

A bug is behavior that differs from what the software is supposed to do. A button that saves the wrong record is a bug. A page that loads in twelve seconds is a bug. A price that rounds a cent in the wrong direction is a bug. The word covers everything from a cosmetic typo to a failure that stops the business.

Every non-trivial codebase has bugs, and this is worth stating plainly because outside software it sounds like an admission of sloppiness. It is closer to a law of the material. A working product holds millions of possible states: every browser, every screen size, every odd sequence of clicks, every record in the database with an unexpected shape. A developer writing a change can reason about a handful of those states. The rest are discovered by tests, by reviewers, or by customers. Teams differ enormously in how many bugs they ship and how fast they fix them, and that difference comes from process, the safety nets in the rest of this lesson, far more than from individual carefulness.

The name has a real origin. In 1947, operators of an early Harvard computer traced a failure to an actual moth caught in a relay and taped it into the logbook. The word was older engineering slang, but the story stuck.

What is a test suite, and what is QA?

A test suite is code whose only job is to check the product's code. A single test sets up one situation, runs one piece of the product, and confirms the result matches what was expected: charge this card, and the order total should equal the sum of the items. A suite is hundreds or thousands of these, and the practice as a whole is called automated testing.

The suite earns its keep through CI/CD, which runs every test against every pull request automatically. A change that breaks an existing test gets stopped before any human even reviews it. This is what allows the shipping rhythm from the last lesson: a team can merge and deploy many times a day precisely because a machine re-checks the whole product each time. When a developer says a codebase "has good coverage," they mean the suite checks most of what the product does, so changes there are safe to make quickly.

Some developers write the test before the code it checks, a practice called test-driven development, or TDD. The test fails at first, because the feature does not exist yet, and the developer then writes code until it passes. A candidate who names TDD is describing a working style, and a strong opinion about it either way is common and unremarkable.

QA stands for quality assurance: testing done by people rather than by the suite. A QA engineer explores the product the way an adversarial customer would, probing the odd paths automated tests miss, and often builds automated tests as well. Twenty years ago most companies had large separate QA departments that checked every release by hand. Automation absorbed much of that work, and at many companies today developers test their own changes, with QA as a specialty on the team. Both models are live.

What is on-call?

On-call is a rotation in which one developer is, for a set period, the person who answers when the live product breaks. Software runs around the clock, so someone has to be reachable around the clock. The on-call engineer carries the pager, in practice a phone app, and when monitoring detects a failure at 3 a.m., their phone goes off and they are expected to respond within minutes.

Rotations usually run a week at a time across a team, so each developer might carry the pager one week in six. A quiet week costs low-grade alertness. A bad week means interrupted nights and a workday spent tired. Teams treat the quality of their on-call as a measure of engineering health: a service that pages rarely reflects good tests and good design, and a service that pages nightly is a known emergency. On-call is standard for backend and infrastructure roles at product companies, and compensation for it varies from nothing to meaningful extra pay.

What is an incident?

An incident is a failure in the live product that customers can feel. The site is down, checkout errors out, or the app serves the wrong data. The word marks the difference between a bug sitting quietly in the code and a bug actively burning: an incident is happening now, in production, and the clock is running.

Teams handle incidents with a practiced routine. The alert fires, the on-call engineer responds, and if the problem is large, more people join a dedicated channel or call. The first goal is restoring service, often by rolling back the change that caused it, and understanding the root cause comes second. Severity levels grade the response: a "sev1" is the building-on-fire tier where executives get woken up, while lower severities wait for morning.

Afterward comes the postmortem, a written account of what happened: the timeline, the cause, the customer impact, and the specific changes that will prevent a repeat. Good teams run these as "blameless," meaning the document names broken processes rather than guilty people, because an engineer afraid of blame hides information the team needs. A developer who talks fluently about incidents they have handled has operated real software under pressure, and developers who have carried that weight tend to recognize the fluency in each other.

What is technical debt?

Technical debt is the future cost of shortcuts taken in the past. A team facing a deadline builds the quick version instead of the sound one, on purpose, and ships. The product works. The shortcut stays in the code, and every later change that touches it takes longer, breaks easier, and needs more care. That accumulating drag is the debt, and like financial debt it compounds: the interest is paid in slower work, forever, until the principal gets repaid.

The finance metaphor is the point of the name, and it was coined by programmer Ward Cunningham to explain exactly this trade to non-engineers. Borrowing can be smart. A startup racing to find customers is right to take on debt, because sound code for a product nobody wants is worthless. The debt becomes a problem when nobody tracks it or repays it, and a mature product team budgets ongoing time for repayment the same way a household budgets for a mortgage.

For hiring, the phrase decodes a great deal of job-description language. "Modernizing our platform," "improving developer velocity," and "hardening core services" all describe roles where paying down debt is a major share of the work. That work is demanding and senior, because changing old load-bearing code safely calls for more skill than writing new code on a blank page.

What is refactoring, and why do developers ask for time to do it?

Refactoring is improving the internal structure of code without changing what it does for users. The word is precise on that second half: after a refactor, customers see nothing. The renovation happened inside the walls, and the test suite is what proves the behavior stayed identical while the structure changed underneath it. Refactoring is how technical debt gets repaid.

This creates a communication problem inside companies, because refactoring consumes weeks of expensive engineering time and produces nothing a customer or an executive can see. What it produces is speed later: features that would have taken a month now take a week, and whole categories of bugs stop appearing. When developers lobby for cleanup time or push back on a roadmap because "we need to slow down and refactor first," they are making an investment argument, spend now to move faster after, about costs that are invisible from outside the repository.

Engineers notice quickly which non-engineers understand this trade, and a recruiter who does holds an unusual credential. It also completes the picture this lesson opened with. Software is never finished because the product keeps changing, the changes create bugs and debt, and the tests, the rotations, and the refactoring are the permanent upkeep that keeps the whole thing standing. The module guide places this upkeep alongside the building, and a later lesson covers the people who carry it as their whole job.