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.

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.
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.
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.
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.
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.
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.
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.
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.
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.
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