Software Engineering Glossary

Writing Python is only one slice of a working software developer’s job. The rest happens around the code: planning what to build, agreeing how the team will work, reviewing each other’s changes, getting code safely from a laptop to production, and keeping it healthy once it’s running. The Software Engineering Glossary collects the vocabulary that surrounds those activities.

These terms aren’t Python-specific, but they show up constantly in Python jobs, open source projects, and team conversations. Skim this area when you need to know what a flaky test, a hotfix, a software bill of materials (SBOM), or the ever-dreaded technical debt actually is.

Each entry gives a short, plain-language definition, a diagram and example where it helps, and pointers to neighboring concepts.

  • agile An approach to software development that delivers work in short, repeated cycles and treats changing requirements as normal rather than a planning failure.
  • architecture decision record (ADR) A short, dated document that captures a single architecturally significant decision, the context that forced it, and its consequences.
  • behavior-driven development (BDD) A software development practice that captures what a feature should do as plain-language examples, then keeps them as executable documentation.
  • blue-green deployment A release strategy that runs two identical production environments, one live and one idle, and switches all traffic to the new version at once.
  • canary release A deployment strategy that ships a new version to a small slice of users first, watches it, and widens to everyone only if it stays healthy.
  • containerization A practice that packages an application and its dependencies into a portable, isolated unit called a container that runs the same anywhere.
  • continuous delivery A software practice that keeps every change deployable through an automated pipeline, so a team can release to production on demand, not as a rare event.
  • continuous deployment A release practice where every change that passes the automated pipeline goes straight to production, with no manual approval step.
  • continuous integration A practice of merging every developer’s work into a shared mainline daily, where an automated build runs the tests on each change to catch problems early.
  • definition of done A shared checklist of quality criteria that every piece of work must meet before a team considers it finished and ready to release.
  • distributed tracing An observability technique that follows a request across multiple services, recording each step as a timestamped span on one shared timeline.
  • error budget A reliability allowance derived from a service-level objective (SLO), calculated as 1 minus the SLO, that a team can spend on outages and risky changes.
  • feature flag A switch in your code that turns a feature on or off at runtime, letting a team deploy code without releasing the feature to users yet.
  • flaky test An automated test that passes sometimes and fails other times on the same code, eroding trust in continuous integration.
  • hotfix A narrowly scoped, urgent software change shipped to production outside the regular release cycle to fix a critical bug or security issue.
  • incident An unplanned event that disrupts or degrades a service, or threatens to, and needs an immediate response from the team running it.
  • infrastructure as code (IaC) A practice of managing computing infrastructure through machine-readable configuration files, applied by tools like Terraform, Pulumi, or CloudFormation.
  • kanban A workflow method that shows work as cards on a board and caps work in progress, so a team pulls in new tasks only as capacity frees up.
  • microservice A small, independently deployable service that owns one slice of an application and talks to the rest of the system over a lightweight network API.
  • minimum viable product (MVP) A minimal first version of a new product, shipped to test an idea with the least effort and learn whether it’s worth building further.
  • observability A practice for understanding a software system’s behavior from the outside by analyzing the signals it emits, grouped into logs, metrics, and traces.
  • pipeline An automated sequence of stages that takes a code change from a commit to a tested, deployable result, running the same steps on every push.
  • retrospective A recurring team meeting where a group reviews how it has been working and agrees on a few concrete changes to improve the next cycle.
  • rollback A return to the previous, known-good version of a system after a bad deploy, undoing the change as if it had never shipped.
  • rolling deployment A release strategy that ships a new version by replacing a service’s instances a few at a time, so the fleet keeps serving traffic with no downtime.
  • runbook A documented, step-by-step procedure for a specific operational task or known issue, so anyone on call can resolve it without improvising.
  • scrum A lightweight agile framework that organizes work into short, fixed-length sprints with defined roles, events, and artifacts.
  • semantic versioning (SemVer) A convention for numbering releases as MAJOR.MINOR.PATCH so each number says whether an upgrade is a bug fix, a new feature, or a breaking change.
  • service-level agreement (SLA) A contract with customers that promises a level of service and attaches consequences, such as refunds, to missing it.
  • service-level indicator (SLI) A quantitative measure of one aspect of how a service is performing, such as the share of requests that succeed or their latency.
  • service-level objective (SLO) A target value or range for a measured aspect of a service, such as 99.9 percent of requests succeeding over thirty days, that a team commits to.
  • smoke test A small, fast set of tests that runs after a build or deploy to confirm a system’s most critical paths still work.
  • software bill of materials (SBOM) A formal, machine-readable inventory of every component, version, and dependency that goes into building a piece of software.
  • software development life cycle (SDLC) A structured sequence of phases that software moves through, from planning and design through building, testing, deployment, and ongoing maintenance.
  • sprint A fixed-length timebox, usually one or two weeks, in which a team commits to a focused batch of work and aims to finish it.
  • staging environment A production-like environment used as the final gate before release, where a team verifies that a build behaves the way it will in production.
  • standup A short, recurring team meeting where each member shares recent progress, plans, and any blockers, so the team stays aligned day to day.
  • story points A unit of measure an agile team uses to size a backlog item by relative effort, complexity, and uncertainty instead of by hours.
  • technical debt A metaphor for the accumulated future cost of an expedient software design, paid back later as slower changes, more bugs, and harder maintenance.
  • test pyramid A heuristic that spreads automated tests across layers, with many fast unit tests at the base and only a few slow end-to-end tests at the top.
  • threat modeling A structured security exercise that maps how a system works, identifies what could go wrong, and chooses a response for each risk.
  • twelve-factor app A methodology of twelve practices for building portable, scalable, cloud-deployable web services from a single shared codebase.
  • user story A short, plain-language description of a software feature told from the user’s perspective, capturing who wants it, what they want to do, and why.
Reference Share Feedback