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.
Not sure which term you need? Describe what you’re trying to do, and Mentor AI will point you to the right entries.
agileAn 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 deploymentA release strategy that runs two identical production environments, one live and one idle, and switches all traffic to the new version at once.
canary releaseA 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.
containerizationA practice that packages an application and its dependencies into a portable, isolated unit called a container that runs the same anywhere.
continuous deliveryA 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 deploymentA release practice where every change that passes the automated pipeline goes straight to production, with no manual approval step.
continuous integrationA 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 doneA shared checklist of quality criteria that every piece of work must meet before a team considers it finished and ready to release.
distributed tracingAn observability technique that follows a request across multiple services, recording each step as a timestamped span on one shared timeline.
error budgetA 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 flagA 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 testAn automated test that passes sometimes and fails other times on the same code, eroding trust in continuous integration.
hotfixA narrowly scoped, urgent software change shipped to production outside the regular release cycle to fix a critical bug or security issue.
incidentAn 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.
kanbanA 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.
microserviceA small, independently deployable service that owns a single business capability 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.
observabilityA practice for understanding a software system’s behavior from the outside by analyzing the signals it emits, grouped into logs, metrics, and traces.
pipelineAn automated sequence of stages that takes a code change from a commit to a tested, deployable result, running the same steps on every push.
postmortemA written record a team produces after an incident to capture what happened, why it happened, and what to change so the same failure doesn’t recur.
retrospectiveA recurring team meeting where a group reviews how it has been working and agrees on a few concrete changes to improve the next cycle.
rollbackA return to the previous, known-good version of a system after a bad deploy, undoing the change as if it had never shipped.
rolling deploymentA 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.
runbookA documented, step-by-step procedure for a specific operational task or known issue, so anyone on call can resolve it without improvising.
scrumA lightweight agile framework that organizes work into short, fixed-length sprints with defined accountabilities, 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 testA 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.
sprintA 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 environmentA production-like environment used as the final gate before release, where a team verifies that a build behaves the way it will in production.
standupA short, recurring team meeting where each member shares recent progress, plans, and any blockers, so the team stays aligned day to day.
story pointsA unit of measure an agile team uses to size a backlog item by relative effort, complexity, and uncertainty instead of by hours.
technical debtA metaphor for the accumulated future cost of an expedient software design, paid back later as slower changes, more bugs, and harder maintenance.
test pyramidA 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 modelingA structured security exercise that maps how a system works, identifies what could go wrong, and chooses a response for each risk.
twelve-factor appA methodology of twelve practices for building portable, scalable, cloud-deployable web services from a single shared codebase.
user storyA 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.
