Glossary of IT terms

a controlled experiment on live users

An experiment that shows two versions of something to randomly split groups of users at the same time and compares a chosen metric between them. It is the strongest evidence of an effect and the dearest: telling a rate of 18% from 19% takes about 24,000 users in each group.

Explained in full: /management/product-management/product-discovery

how this story will be judged done

The conditions one piece of work must meet to be accepted, agreed before it is built — for example, that an expired promo code is rejected with its expiry date. They differ from a Definition of Done, which applies to every piece of work; fifteen of them on one story usually means it is several stories.

Explained in full: /management/decomposition/user-stories

the four promises of a transaction

The four guarantees of a database transaction: all of it happens or none of it does, it never leaves a declared rule broken, concurrent transactions do not see each other half-finished, and a confirmed commit survives a crash. Isolation comes with settings, and the default in most engines is weaker than the name suggests.

Explained in full: /development/databases/sql

5–12 teams that plan and deliver together

In SAFe, a long-lived group of five to twelve agile teams, usually 50 to 125 people, that plan together at PI Planning, work to the same iteration boundaries and integrate their work every iteration. It should be drawn around the path a product takes to its customers; a train drawn around the existing departments coordinates them without changing anything.

Explained in full: /management/methodologies/safe

contract between programs

The rules one program follows to call another: which requests it may send, in what shape, and what comes back. To the caller it is a contract — everything behind it stays a black box, which is exactly what lets the other side be rewritten without breaking you.

Explained in full: /development/architecture/api-design

records added, never changed

A store or log in which new records are only ever added and existing ones are never changed or deleted in place; a correction is a new record pointing at the old one. It costs space and turns "the current value" into a query, and in return nothing that was once known can silently disappear.

open-source autopilot

An open-source autopilot for multirotors, planes, helicopters, boats and ground vehicles, licensed under the GPLv3. It covers the same ground as PX4 — stabilisation, navigation, modes, failsafes — with a wider range of vehicle types and a copyleft licence that matters the day you ship modified firmware.

accessibility attributes

A set of HTML attributes — role, aria-label, aria-expanded and the rest — that tell assistive technology what an element is and what state it is in. It only describes; it implements nothing: role="button" makes a screen reader announce a button, and the element still ignores the keyboard until you write that code yourself.

the ordered list of what is left

The ordered list of everything that might be built, with the most valuable at the top. Ordered is the operative word: a backlog where everything is equally important is a wish list, and it makes no decision easier.

Explained in full: /management/methodologies/scrum

waiting longer between retries

Waiting before retrying a failed call, and waiting longer after each failure — for example 1, 2, 4 and 8 seconds — usually with a random jitter added so that many clients do not retry at the same moment. Without it, retries arrive exactly when the struggling service can least afford them.

how far the damage spreads

How much of a system is affected when one thing goes wrong — a bad deploy, a crashed process, a leaked credential, an agent’s mistake. It is kept small with boundaries: separate processes, narrow permissions, staged rollouts. The trade-off is that every boundary which contains a failure also costs something to cross.

two environments, one switch

Two identical environments where only one serves traffic: the new version goes to the idle one, and release is a switch between them. Rollback is the same switch back, which is why it is measured in seconds rather than in a redeploy.

Explained in full: /management/release-process/release-planning

a change users must adapt to

A change after which existing users must change their own code or configuration to keep working — a removed or renamed field, a stricter validation rule, a new default. Under semantic versioning it needs a new major version, and it is the change most often shipped by mistake as a fix.

Explained in full: /management/release-process/changelog

an isolated profile in one browser

An isolated session inside one running browser, with its own cookies, storage and permissions, as Playwright uses it. Opening one takes milliseconds rather than a browser launch, so each test can start as a fresh user, and two contexts in one test are two users who cannot see each other.

Explained in full: /qa/automation/playwright

instructions for a virtual machine

Compact instructions for a virtual machine rather than for a real processor — what the JVM, CPython, PHP’s OPcache, React Native’s Hermes and the Ethereum Virtual Machine run. A compiler produces it from source code ahead of time, so the runtime skips parsing; the virtual machine then interprets it or compiles the busy parts further into machine code.

Explained in full: /development/backend/java

command and control software

Software that turns reports from many sources into one shared picture people can act on, and carries the decisions made from it. Its central job is correlation — deciding whether two reports describe one thing or two — which is why it is harder than the map it is usually drawn as.

Explained in full: /deftech/c2-systems

release to a few first

Sending the new version to a small share of traffic first and watching before the rest follows. It buys the one thing a full release cannot: a failure that costs you one percent of users instead of all of them.

Explained in full: /management/release-process/release-planning

the WIP limit split between kinds of work

Dividing a team’s work-in-progress limit between kinds of work in advance — say five planned items, three support requests and one improvement — usually drawn as separate lanes on the board. The split is argued once rather than for every request, and when it proves wrong the measures show it.

Explained in full: /management/methodologies/scrumban

streaming changes from a database log

Streaming every insert, update and delete from a database’s own change log to other systems, as tools such as Debezium do. It keeps a second copy in sync without the application writing twice, at the price of coupling every consumer to the source’s table layout.

deployments that break something

The share of deployments to production that need immediate intervention — a rollback, a hotfix or a fix forward. One of DORA’s delivery metrics, and an easy one to game by not calling things failures, so it is read beside recovery time, never alone.

Explained in full: /management/release-process/release-planning

a formal request to change something agreed

A formal request to change something already agreed — the scope, a design, a live system — which is assessed for its effect on cost, time and risk, and approved or rejected before any work starts. It is how a signed baseline absorbs new information; treated as a failure rather than as information, it becomes the way a plan is defended past its usefulness.

Explained in full: /management/methodologies/waterfall

the record of what changed, per version

A file, usually CHANGELOG.md, that lists the notable changes in each version of a piece of software, newest first, grouped as added, changed, deprecated, removed, fixed and security. It is written for the person deciding whether to upgrade, which is why a dump of commit messages does not count as one.

Explained in full: /management/release-process/changelog

breaking things on purpose

Deliberately causing failures in a running system to find out what it does before the failure happens by itself. The point is timing rather than bravado: the same instance dying at 3 a.m. unrehearsed is an incident, and at 2 p.m. with the team watching it is a finding.

how tools drive Chrome

The protocol Chrome’s developer tools use to inspect and control the browser, open to any program that connects to it. Test tools such as Playwright and Puppeteer drive Chromium through it, so they see the browser’s state directly rather than through the page.

automatic build, test and delivery

Every commit is built and put through the tests automatically (CI), and a build that passes travels to the servers the same way (CD). The point is not automation for its own sake: it is that a breakage shows up in minutes instead of on release day.

Explained in full: /infrastructure/devops/ci-cd

control by typed commands

Driving a program by typing commands instead of clicking. The real advantage is not typing speed: any command can be put in a script and repeated exactly, with no human in the loop — which is what makes automation possible at all.

the older Node module system

Node.js’s original module system — require where modern code writes import. It still coexists with ES modules, and most of the baffling import errors in Node happen exactly on the border between the two.

Explained in full: /development/backend/nodejs

re-running a bug’s steps after the fix

Testing done after a defect is fixed: the steps that exposed it are run again to confirm the failure no longer happens. It proves one fix; keeping those steps as a permanent regression case is what stops the bug coming back unseen.

Explained in full: /qa/types-of-testing/smoke-testing

all the model can see at once

The maximum number of tokens a language model can have in front of it on a single call, holding the instructions, the conversation, any documents and the answer being written. It is not storage: nothing survives between calls, so a chat only has a history because the application resends it every time.

Explained in full: /development/ai-llm/llm-fundamentals

data the browser sends back

A small piece of data a website asks the browser to keep and send back with every request to that site — which is how a server remembers that you are signed in. Because the browser attaches it automatically, even to a request another site triggered, a session cookie needs its flags set and an anti-forgery check on the server.

Google’s page-experience metrics

Three measurements Google takes from real visitors’ browsers: LCP, how fast the main content appears; INP, how fast the page responds to input; and CLS, how much the layout jumps. They feed into search ranking, but only as one signal among many — a fast page with nothing worth reading still loses to a slow one that answers the question.

what one more week of waiting costs

How much value is lost for each unit of time a piece of work waits — high from the first minute for an outage, nothing until the deadline for a regulatory date, steadily growing for ordinary work. Putting even a rough number on it is what lets a team compare urgency instead of arguing about it.

Explained in full: /management/methodologies/kanban

the processor

The processor that executes a program’s instructions. Calling a task “CPU-bound” means it is limited by computation rather than by waiting on disk or network — and the two need opposite fixes, so the distinction is worth making early.

holding every skill the work needs

Said of a team that holds every skill needed to take its work from idea to production — design, development, testing, operations — so it does not wait for other departments to finish their part. The trade-off is depth: specialists spread across teams need another structure, such as a chapter or a guild, to keep their craft consistent.

Explained in full: /management/leadership/org-structures

stacked bands of work by stage over time

A chart that plots, for every day, how many items have entered each stage of a workflow so far, drawn as stacked bands. The vertical gap between two lines is the work in progress between them and the horizontal gap roughly how long an item spends there, so a band that keeps widening marks a bottleneck.

Explained in full: /management/methodologies/kanban

a public ID for a known vulnerability

A public identifier for a known security flaw, such as CVE-2021-44228 for Log4Shell, so that vendors, scanners and advisories all mean the same bug. The number says a flaw exists; how dangerous it is for you depends on whether you run the affected version and expose the affected part.

from start of work to done

The clock from the moment work actually starts to the moment it is done — lead time minus the waiting before anyone picked it up. The gap between the two is the queue, and it is usually where the improvement is.

Explained in full: /management/methodologies/kanban

the team’s 15-minute re-plan

A fifteen-minute event, every working day, where the Developers inspect progress toward the Sprint Goal and re-plan the next twenty-four hours. It is not a status report: if it only works with a manager in the room, it has already become one.

Explained in full: /management/methodologies/scrum

two threads, one variable, no lock

Two threads or goroutines accessing the same memory at the same time, at least one of them writing, with nothing to order the accesses. The result is undefined — a wrong value, a torn read or a crash much later — and unlike a race condition in logic it can be ruled out mechanically: by a race detector or, in Rust, by the compiler.

Explained in full: /development/backend/go

what "finished" means here

The checklist a piece of work must pass before anyone may call it done — tested, reviewed, documented, deployed, whatever the team agreed. Its value is that "done" stops being a matter of opinion in a status meeting.

Explained in full: /management/methodologies/scrum

dependencies handed in from outside

Instead of creating the objects it needs, a class receives them ready-made from outside. This is the thing that makes code testable: in a test you hand it a fake where production hands it the real database.

services that must still ship together

A system split into services that still cannot be deployed independently — they share a database, must be released in a fixed order, or call each other synchronously for every request. It keeps the coupling of a tangled monolith and adds network failures, which is why it is worse than either a monolith or real microservices.

Explained in full: /development/architecture/monolith

the page as a tree of objects

The tree of objects a browser turns an HTML page into, so that code can read and change it. Change the DOM and the reader sees the change immediately; the HTML file the server sent stays exactly as it was.

Explained in full: /development/frontend/html-css

research on software delivery

A research programme, now run by Google Cloud, that has surveyed software teams every year since 2014 and gives the industry its standard delivery metrics — lead time, deployment frequency, recovery time, change fail rate and, since 2024, rework rate. Its central finding is that speed and stability go together; its performance levels are one year’s survey answers, not targets.

Explained in full: /management/release-process/release-planning

a test that drives the real app

A test that goes through the whole system the way a user does — real browser, real requests, real database. It catches what nothing else catches and costs the most to keep alive, so a suite of them is kept deliberately small.

Explained in full: /qa/types-of-testing/e2e-testing

the budget of work actually finished

The budgeted cost of the work actually finished so far, compared with what the plan said should be finished (planned value) and what was really spent (actual cost). It measures progress only as honestly as “finished” is defined, which is why it works best on small work packages counted as done or not done.

Explained in full: /management/decomposition/work-breakdown-structure

turns text into coordinates

A model that converts a piece of text, an image or a product into a list of numbers positioned so that similar things land near each other, which is what lets a search match meaning rather than words. The same one must be used for the documents and for the questions: vectors from two different models are not comparable.

Explained in full: /infrastructure/mlops/vector-databases

work that makes later work possible

A backlog item no user asked for that makes later items possible: research, architecture, infrastructure or compliance work, in SAFe’s four types. Naming it lets that work compete for capacity openly instead of hiding inside the estimates of user stories.

Explained in full: /management/decomposition/epics-features-tasks

a large backlog item

A large piece of work that is split into features or stories before anyone builds it, best written as a bet with a hypothesis and a condition that closes it. Its size depends on whose vocabulary is in use — anything above a story in Jira, a portfolio investment with a business case in SAFe — so check before comparing two epics.

Explained in full: /management/decomposition/epics-features-tasks

the test suite for a model

A fixed collection of inputs with a way to judge each output, run before and after every change to a prompt, a model or a retrieval step, and reported as rates rather than pass or fail. Its job is to fail: a set built from cases the system already handles reports a high score forever and detects nothing.

Explained in full: /development/ai-llm/llm-ops

one thread taking turns

A loop on a single thread that takes finished work from a queue — a reply that has arrived, a timer that has fired — and runs its callback, one at a time. It lets one thread juggle thousands of waits, and it stops for everyone while any single callback runs.

Explained in full: /development/frontend/javascript

copies agree — later

A guarantee that copies of the data will agree once writes stop arriving, with no promise about when. Until then a read can return an older value than the one just written, so a user may not see their own change on the next screen unless that read goes to where the write was made.

Explained in full: /development/databases/nosql

a schema change in reversible steps

Changing the shape of data in three releases instead of one migration: add the new structure and write to both, move the readers across, then remove the old structure once nothing reads it. Every step but the last can be undone, which is the point — a rename done in one migration has no way back.

Explained in full: /management/release-process/release-planning

the class of work for emergencies

The Kanban class of service for genuine emergencies: an expedite item jumps the queue and ignores the WIP limit. It only works with a strict cap, usually one at a time — without one, every request someone senior cares about becomes an emergency.

Explained in full: /management/methodologies/kanban

the engineering-first agile method

An agile methodology from the late 1990s built around engineering practices: test-first development, pair programming, continuous integration, refactoring and small, frequent releases. Much of what teams now call technical agility comes from it, and a team that adopts Scrum’s events without these practices usually watches its sprints slow down.

pre-set reaction to a failure

A behaviour configured in advance for one specific failure — the link lost, the position lost, energy running low — which the vehicle carries out on its own, with nobody asked. The table of failsafes, not the mission plan, decides what an uncrewed aircraft actually does when something goes wrong.

Explained in full: /deftech/drone-software

a switch around new code

A switch that decides at run time whether a piece of code is active, so it can ship to production turned off and be turned on for a chosen audience later. It separates deploying from releasing, and it costs something: every live flag is a branch in the code that has to work in both states.

Explained in full: /management/release-process/release-planning

a team that owns features end to end

A long-lived, cross-functional team that takes a customer-visible piece of the product from idea to done, working in every component it touches. The alternative is component teams, one per technical layer, where one feature waits in several teams’ queues; the price of feature teams is learning to work in code the team did not write.

Explained in full: /management/methodologies/less

training on your own examples

Continuing a model’s training on examples you supply, so behaviour you keep describing in the prompt becomes what it does by default. It teaches form, tone and judgement well and facts badly: a fact absorbed into weights comes back approximately, cannot be cited and cannot be corrected without training again.

Explained in full: /development/ai-llm/fine-tuning

agreed scope, agreed sum

A contract where an agreed scope is delivered for an agreed sum, so the supplier carries the cost of anything that takes longer than planned. That is why fixed-price work comes with the strictest change control: every change to the scope is a commercial event, not just a planning one.

passes and fails on the same code

A test that passes and fails on unchanged code. The real damage is not the failed run but what follows: once a suite has a few, people start re-running until green, and the suite stops being evidence of anything.

Explained in full: /qa/types-of-testing/regression-testing

a column pointing at another table’s row

A column whose value must match the key of a row in another table — an order’s customer id must name a customer who exists. The database refuses any row that breaks the rule, whoever writes it; across services, where no single database can check it, the rule becomes the application’s job.

Explained in full: /development/databases/data-modeling

frees memory nobody uses

The part of a runtime that finds objects nothing refers to any more and frees their memory, so the program never frees it by hand. The price is extra memory and work the program does not schedule — pauses, short or long depending on the collector.

Explained in full: /development/backend/java

EU personal-data law

The European regulation governing personal data: what you may collect, on what legal basis, how long you may keep it, and what a person can demand you do with theirs. It applies by where the people are, not by where the company is, which is why it reaches software built anywhere.

a target stops being a measure

The observation, named after the economist Charles Goodhart (1975), that a measure stops being a good measure once people are rewarded for moving it. Nobody has to cheat for it to happen; the usual defence is a second, guardrail metric that would break if the first were gamed.

Explained in full: /management/product-management/metrics-kpi

a processor for parallel maths

A processor built from thousands of simple cores that apply the same operation to large arrays of numbers at once. That shape happens to be exactly what training and running models needs, which is why GPUs long ago stopped being only about graphics.

a query language for APIs

An API style in which the client sends a query naming exactly the fields it wants and gets back a response of that shape, usually from a single endpoint. It saves round trips for rich clients, and in exchange gives up ordinary HTTP caching and leaves the server to limit what each query may cost.

Explained in full: /development/architecture/api-design

confident invented output

A model stating something invented with the same fluency it states something true. It is not a bug to be patched out: the model predicts plausible text, and plausible is not the same as correct — which is why anything checkable gets checked.

Explained in full: /development/ai-llm/llm-fundamentals

real board, simulated world

Testing in which the real controller board runs its real firmware, wired to a simulator that feeds it sensor data in place of the physical world. It finds timing faults, processor load and driver bugs that pure simulation cannot, at the cost of keeping the hardware on a bench.

examples never trained on

Examples separated out before training or tuning begins and never used to change the thing being measured. Without one there is no way to tell a model that learned the task from one that memorised the examples — and the second scores perfectly on everything anybody looked at.

Explained in full: /development/ai-llm/fine-tuning

tamper-resistant key store

A tamper-resistant device that stores cryptographic keys and performs signing inside itself, so the key is used but never handed out. A compromised build server can still ask it to sign, which is why production signing also needs a log and a second person.

the protocol of the web

The protocol browsers and servers talk in: the client sends a method and an address, the server answers with a status code and a body. It keeps no memory between requests — every request stands alone, which is why anything that must be remembered is carried explicitly.

a request id that makes a retry safe

A unique value a client sends with a request that changes something — a payment, an order — so the server can recognise a repeat and return the first result instead of acting twice. The server has to store the keys and decide how long to keep them; a retry that arrives after its key has expired is treated as new.

Explained in full: /development/architecture/api-design

safe to repeat

An operation that has the same effect whether it runs once or five times. It is what makes a retry safe — and since any network call may be retried without you knowing, the alternative is charging a card twice.

radio challenge and reply

A system in which a transponder answers a coded radio interrogation, so that a sensor can tell a friendly aircraft from an unknown one. A reply is evidence about the transponder rather than the aircraft: a missing reply may be a broken transponder, and a reply read from the wrong place belongs to someone else.

a page inside a page

An HTML element that embeds another document inside a page — a payment form, a video, a sign-in box. When it comes from another origin, the browser walls it off from the page around it, which is why a test tool may or may not be able to type into it.

the working result of a sprint

Everything finished so far, taken together and actually working — not the pile of tickets closed this sprint. The test is whether it could be released today, even if the decision is not to.

Explained in full: /management/methodologies/scrum

testing certification body

The international body behind the most widely taken software-testing certifications, which also publishes a glossary of testing terms. Its definitions are a common reference in interviews and contracts; they fix vocabulary, not how a team has to work.

compiling while running

Compiling code while the program is already running: the runtime interprets it at first, watches which parts are hot, and turns those into machine code on the fly. That is why the first seconds after start are slower than the minutes that follow.

text format for data

A text format for passing data around: key–value pairs, lists, numbers and strings. It came out of JavaScript, but every language reads it now, and that is why most APIs answer in it rather than in anything more capable.

markup written inside code

A syntax that lets you write markup directly in JavaScript. It is not HTML embedded in code but a shorthand: before the code runs, every tag is turned into an ordinary function call.

Explained in full: /development/frontend/react

hardware debug port

A standard test and debug interface built into most chips, through which a connected probe can halt the processor, read memory and write firmware. Indispensable on the bench and the first thing anyone looks for on a captured board, which is why production units lock or disable it.

the runtime Java runs on

The machine compiled Java code actually runs on. It supplies the garbage collector and the JIT, and it is the reason one build runs unchanged on Windows, Linux and macOS — the platform difference is the JVM’s problem, not the program’s.

Explained in full: /development/backend/java

how satisfaction responds to a feature

Noriaki Kano’s 1984 classification of features by how customer satisfaction responds to them: must-be (no praise when present, anger when absent), one-dimensional (more is better), attractive (delight when present, not missed when absent), indifferent and reverse. It says what customers expect, not what to build first.

Explained in full: /management/product-management/roadmapping

a number that tracks health

A number chosen to show whether something is going well. The failure mode is built in: once a KPI becomes a target people are rewarded against, it stops measuring what it was picked to measure.

Explained in full: /management/product-management/metrics-kpi

from request to delivery

The clock from the moment a request is made to the moment it is delivered — the whole wait, including the time it spent in a queue nobody was looking at. It is what a customer experiences, which is why it is usually far longer than anyone inside expects.

Explained in full: /management/methodologies/kanban

an early, imperfect signal

A metric that moves early and predicts a later result imperfectly — how many customers use a new feature in its first weeks, as a signal of next quarter’s retention. Its opposite, a lagging indicator such as revenue, is accurate but arrives too late to act on.

Explained in full: /management/product-management/metrics-kpi

restart-if-stuck check

A periodic check the platform runs against a container to decide whether to restart it, meant to catch a process that is stuck, such as a deadlock. It should test only the process itself: point it at a dependency, and a slow database restarts every container at once.

Explained in full: /infrastructure/devops/kubernetes

running LLM features in production

The practices for running a feature built on a language model in production, rebuilt around the fact that the same input does not give the same output. An evaluation set replaces the test suite, the deployed unit is code plus prompt, model and index versions, and a wrong answer is only reproducible if the whole call was traced.

Explained in full: /development/ai-llm/llm-ops

spreads requests across servers

A server or managed service that receives incoming requests and spreads them across several copies of an application, skipping any copy that fails its health check. It is also one more network hop with its own timeouts, so its settings and the application’s have to agree.

how a test finds an element

A description of how a browser test finds an element — by role and name, by label, by text or by a test id — resolved again each time it is used. Because it is a recipe rather than a reference, it finds the current element on a page that re-renders, and a good one survives a redesign.

Explained in full: /qa/automation/playwright

exact versions of every dependency

A file the package manager writes next to the list of dependencies, recording the exact version of every package installed — including the ones your dependencies pulled in. Committed to the repository, it makes every install identical; without it, two builds of the same commit can run different code.

a release patched for years

A release line that keeps receiving security and critical fixes for a published period after newer versions ship, but no new features. It lets a team upgrade on its own schedule — until the end date on the support table, after which the next vulnerability has no fix at all.

one person, one working day

A unit of effort: one day of one person’s work, usually eight hours — the unit quotes, fixed-price bids and time-and-materials invoices are counted in. It measures effort, not calendar time: twenty man-days is not four weeks for anyone until focus, meetings and dependencies are accounted for.

Explained in full: /management/leadership/estimation

where priorities across teams are set

A regular forum, at least once per Sprint, where Product Owners and the stakeholders with authority agree one order of work for a group of teams; the Executive MetaScrum does it for the whole organisation. Its rule is that priorities change there and nowhere else — without that rule it is one more meeting.

Explained in full: /management/methodologies/scrum-at-scale

a layer every request passes

A layer every request passes through before it reaches your code: authentication, logging, compression. It is written once and applies to all routes, which is the difference between one decision and the same four lines copied into every handler.

one deployable with real module boundaries

A monolith whose code is divided into modules with published interfaces, their own tables and checked boundaries, while it is still built and deployed as one unit. It keeps the cheap calls and transactions of one process; its weakness is that nothing enforces the boundaries unless a check in the build does.

Explained in full: /development/architecture/monolith

simulation by many random runs

A method that answers a question by running it thousands of times with randomly sampled inputs and reading the distribution of the results. On a schedule it replaces a single date with a range and a probability, which is the honest form of an estimate built out of twenty uncertain tasks.

must, should, could, won’t

A prioritisation rule from DSDM that sorts requirements into Must, Should and Could Have, plus Won’t Have this time — the one common model that writes a refusal down. Must Haves should take no more than about 60% of the effort, or nothing is left to give up when the estimate slips.

Explained in full: /management/product-management/roadmapping

one query per row, by accident

The classic ORM trap: one query fetches a list, then the loop over it quietly fires one more query per item — a hundred rows become a hundred and one round trips to the database. The fix is to ask for the related data up front instead of row by row.

Explained in full: /development/databases/sql

right before, wrong after

A case that the old version of a model or prompt got right and the new version gets wrong. Counting them separately matters because an overall score adds fixes and subtracts flips, so a version can score higher and still break things that used to work.

Explained in full: /qa/ai-testing/prompt-regression

the one role Nexus adds to Scrum

The accountability Nexus adds to Scrum: the Product Owner, a Scrum Master and members drawn from the Scrum teams, answerable for a done, integrated increment at least once every Sprint. It coaches the teams to integrate their own work; one that does everyone’s merges has become the hand-off Nexus exists to remove.

Explained in full: /management/methodologies/nexus

databases that are not SQL tables

An umbrella name for databases that do not store relational tables queried with SQL: key-value, document, wide-column and graph stores. Most of them place each record on a machine by a key chosen at design time, which makes queries carrying that key cheap at any size and most other queries expensive or impossible.

Explained in full: /development/databases/nosql

SQL’s marker for “unknown”

The SQL marker for a value that is missing or unknown — not zero and not an empty string. A comparison with NULL is neither true nor false but unknown, so a row holding NULL matches neither “= x” nor “<> x”, and only IS NULL finds it.

Explained in full: /development/databases/sql

a goal with measured results

A goal-setting method that pairs one qualitative objective with two to five measurable key results proving it was reached, set and reviewed every quarter. It stops working when the key results become a task list or the scores feed into pay.

Explained in full: /management/decomposition/okr

a machine-readable API description

A single file describing an HTTP API in a form machines read: routes, parameters, response shapes. Documentation, client libraries and test stubs are generated from it, which is what stops the description from drifting away from the code.

Explained in full: /development/architecture/api-design

a vendor-neutral standard for telemetry

An open-source project that defines how applications produce and send traces, metrics and logs — the libraries, the data format and the protocol — so the tool that stores and shows them can be changed without re-instrumenting the code. It graduated in the Cloud Native Computing Foundation in May 2026. It standardises how telemetry is collected, not what is worth collecting.

objects instead of SQL

A library that hands you language objects where the database has table rows, so you write little or no SQL. The convenience costs control: the query it generates can be far heavier than the one you would have written yourself, and you only find out under load.

Explained in full: /development/databases/sql

updating installed software remotely

An update delivered over the network to software already installed on a device, without the user reinstalling it — a JavaScript bundle for a React Native app, firmware for a phone or a drone. On iOS and Google Play only interpreted code may arrive this way; native code needs a new build and a store review.

Explained in full: /development/mobile/react-native

open application security foundation

A non-profit foundation that publishes free, community-written security guidance — best known for its Top 10 lists of the most critical risks for web applications, APIs and LLM applications. A Top 10 ranks categories of risk to design and test against; it is not a checklist that proves a system safe.

latency for the slowest slice

The response time that 99% of requests come in under — p95 and p50 are the same measure at 95% and at the median. The average hides exactly the requests that make people leave, which is why these are the numbers anyone serious watches.

sizing by simultaneous reveal

A way for a team to size backlog items: everyone picks a card from a fixed scale privately, and all the cards are turned over at once, so nobody anchors on the first voice. Its value is the discussion when the cards disagree — a 2 and a 13 on the same item mean two people understand the task differently.

Explained in full: /management/leadership/estimation

PMI’s project management reference

The Project Management Institute’s reference for managing projects, and the basis of the PMP certification. The edition matters: the 6th (2017) prescribed 49 processes, the 7th (2021) replaced them with twelve principles, and the 8th (2025) has six principles, seven domains and forty processes.

Explained in full: /management/frameworks/pmbok

the office that sets project standards

A unit that sets project-management standards across an organisation, collects reporting from its projects and sometimes employs the project managers. Its value depends on which of those it does: a PMO that only gathers status reports adds a layer without adding a decision.

the smallest unit Kubernetes runs

The smallest thing Kubernetes schedules: one or more containers that share a network address and a lifetime. Pods are disposable by design — one is replaced rather than repaired, which is why nothing worth keeping lives inside it.

Explained in full: /infrastructure/devops/kubernetes

a written review after a failure

A written review held after something went wrong, covering what happened, why, and what changes so it does not happen the same way. The word "blameless" in front of it is not politeness: an engineer who expects to be blamed reports less, and a review that produces a lesson rather than a change to a system has produced nothing.

the column that identifies a row

The column, or set of columns, whose value identifies exactly one row in a table and never repeats. A made-up number or a UUID usually makes a better primary key than a business value such as an email address, because business values change and every reference has to change with them.

Explained in full: /development/databases/data-modeling

owns what gets built

The one person accountable for what the team builds and in what order. The authority is real — a Product Owner who has to get every decision approved elsewhere is a messenger, and the role stops working.

Explained in full: /management/methodologies/scrum

a change proposed for review

A request to merge one branch into another, where the change is reviewed, discussed and checked by the pipeline before it reaches the main branch; GitLab calls the same thing a merge request. Its cost is waiting: a pull request that sits unreviewed for days is where long-lived branches and painful merges come from.

Explained in full: /management/release-process/git-branching-strategy

open-source autopilot

An open-source autopilot for drones, planes and other uncrewed vehicles, hosted by the Dronecode Foundation under the Linux Foundation and licensed BSD. It runs on the flight board and handles stabilisation, state estimation, flight modes and failsafes; the permissive licence is one reason companies build products on it.

fewer bits per number

Storing a model’s weights — or an index’s vectors — with fewer bits per number, typically 8-bit integers instead of 32-bit floats, so they take less memory and run faster. The cost is some accuracy, and whether that cost is acceptable has to be measured on your own data, not assumed.

a bug that depends on timing

A bug that appears only on a particular coincidence in time: two threads or two requests read and change the same thing, and the result depends on who got there first. It reproduces badly, which is why it is usually found last and in production.

find the passages, then answer

Answering a question by first searching your own documents and putting the relevant passages into the prompt, so the model works from them rather than from its weights. It is a search system with a language model on the end, which is why most of its wrong answers are retrieval failures rather than generation ones.

Explained in full: /development/ai-llm/rag-architecture

can-it-take-traffic check

A periodic check the platform runs to decide whether a container should receive traffic; while it fails, requests go to other instances and nothing is restarted. It is the right place to check dependencies, but it still asks about one instance, not about whether the product works.

Explained in full: /infrastructure/devops/kubernetes

share of targets found

The share of the things you were looking for that a system actually found: a recall of 80% means one in five was missed. It is the number that matters when a miss is expensive, and it is traded against precision — how many of the things found were real.

a build meant to become the release

A build the team believes is ready to ship, published so users can try it before the final release. Bugs found now are fixed and no new features are added, but details can still change — so it is for testing, not for production.

resources over plain HTTP

The style most web APIs follow: things are named as resources at URLs, and HTTP methods say what is done to them — GET to read, POST to create, DELETE to remove. Its strength is that every cache, proxy and client library already understands it; in everyday use the word usually just means HTTP with JSON.

Explained in full: /development/architecture/api-design

the meeting that changes the process

The regular meeting where a team examines how it works and changes one thing. A retrospective that ends without a named change someone owns is a complaint session, and teams stop attending it for good reason.

Explained in full: /management/methodologies/scrum

a numbered internet standard

A numbered document published by the IETF, the body that standardises internet protocols; HTTP, TLS and JSON are all defined in RFCs. A published RFC never changes — a correction is a new RFC with a new number, which is why “RFC 9110” names one exact text.

a score for ordering ideas

A prioritisation score from Intercom: reach times impact times confidence, divided by effort, so a big claim with no evidence is marked down. It has no notion of time — a contract date and a nice-to-have score alike — and its inputs are guesses, so the argument it forces is worth more than the ranking.

Explained in full: /management/product-management/roadmapping

detail the near term, outline the rest

Planning the next few months in detail and the rest only as budgeted placeholders, then detailing the next stretch at each planning cycle. It keeps the plan complete without inventing detail nobody can know yet; it fails when the placeholders are never revisited.

Explained in full: /management/decomposition/work-breakdown-structure

a framework for running many agile teams as one

The Scaled Agile Framework: roles, events and practices for coordinating dozens of agile teams, built around the Agile Release Train — five to twelve teams that plan together every eight to twelve weeks. It is the most prescriptive and the most widely adopted scaling framework, which is also why it can be installed without changing who makes the decisions.

Explained in full: /management/methodologies/safe

a multi-service change with an undo per step

A business operation split into a sequence of local transactions in different services, where each step that can be undone has a compensating step that undoes it. It replaces a distributed transaction, at the price of compensations you write yourself and no isolation: other requests can see the half-finished state.

Explained in full: /development/architecture/microservices

a list of what is inside

A machine-readable inventory of every component a piece of software is built from, including the dependencies pulled in by other dependencies. It matters on the day a vulnerability is announced: without one, the question "are we affected?" is answered by guessing.

removes what blocks the team

The person responsible for the process working, not for the work getting done. They remove blockers and protect the team from interruption — they are not the manager of the team, and treating the role as management is the usual way it fails.

Explained in full: /management/methodologies/scrum

a team made of Scrum teams

A group of about four or five Scrum teams on one product that works as if it were a single Scrum team, with representatives meeting daily to remove the blockers between teams. Run as a status meeting of team leads, it keeps the name and loses the purpose.

Explained in full: /management/methodologies/scrum-at-scale

ready-made tools for a platform

A packaged set of libraries, tools and examples for working with someone else’s platform. The difference from an API is that an API only states the rules, while an SDK hands you code that already knows how to speak them.

MAJOR.MINOR.PATCH version numbers

A versioning scheme in which MAJOR goes up for incompatible changes to the public API, MINOR for backward-compatible features and PATCH for backward-compatible fixes, so an upgrade can be judged from the number alone. The number means something only once the public API is declared, and only as long as nobody ships a breaking change as a minor.

Explained in full: /management/release-process/changelog

training data unlike live data

The gap between the data a model was trained on and the data it meets in production. It is the usual reason an excellent offline score turns into a useless live model, and it shows up in the metrics long after the cause.

Explained in full: /infrastructure/mlops/ml-pipelines

the promise with consequences

The contractual promise about a service, with a penalty attached when it is broken. It is the only one of the three that involves lawyers — the target inside it is an SLO, and the measurement behind that is an SLI.

how long an item should take, with a probability

A forecast a Kanban team publishes from its own history: a duration and a probability, such as "85 percent of items finish within 11 days of starting". It describes what the system has been doing rather than promising what it will do, so it changes whenever the system does.

Explained in full: /management/methodologies/kanban

the number actually measured

The measurement itself — the share of requests that succeeded, the actual p99. An SLO is a threshold on an SLI, so an objective set on something nobody measures is a wish rather than a target.

the target you hold yourself to

The internal target — "99.9% of requests under 300ms this quarter". It is deliberately stricter than the SLA, because the gap between them is the room you have to fix something before it becomes a contractual problem.

a program on a blockchain

A program deployed on a blockchain such as Ethereum, which holds funds and state and runs exactly as written whenever anyone calls it. Every node executes it, every step costs gas, and it cannot be changed after deployment unless an upgrade path was built in — so a bug in it is public and usually permanent.

Explained in full: /development/backend/solidity

is this build worth testing?

A small, fixed set of checks run right after a build is deployed, answering one question: is this build worth anyone else’s time? It is a gate, not coverage — it proves the build is testable, never that it is correct.

Explained in full: /qa/types-of-testing/smoke-testing

scores squashed into 0–1

The function a classifier’s last layer usually applies to turn raw scores into numbers between zero and one that add up to one. They look like probabilities but are not calibrated ones, so a softmax of 0.9 does not mean the model is right nine times in ten.

real firmware, simulated world

Testing in which the real control software runs on an ordinary computer against a simulated vehicle, sensors and world. It is fast enough to run on every commit, which makes it a regression suite; what it cannot find is anything that depends on the real processor’s timing.

time-boxed research

A deliberately time-boxed piece of research whose output is an answer, not a feature. The time box is the whole point: a spike without one becomes an open-ended investigation that quietly consumes a sprint.

Explained in full: /management/decomposition/user-stories

a fixed-length work cycle

A fixed period, usually one to four weeks, at the end of which there is something finished enough to show. The length is fixed and the scope moves — a sprint that is extended to fit the work has given up the only thing it was for.

Explained in full: /management/methodologies/scrum

why this sprint exists

One sentence, agreed at Sprint Planning, saying what will be different at the end of the sprint and why it is worth doing. It is what lets a team drop or swap individual items mid-sprint without failing — a sprint judged only by its list of tickets has a quota, not a goal.

Explained in full: /management/methodologies/scrum

the calls in progress at an error

The list of function calls that were in progress when an error was raised, innermost first, printed with the error. It shows where a failure surfaced, which is not always where it was caused — and a process killed from outside, by the kernel or an orchestrator, leaves none at all.

an update released to a growing share of users

Releasing an update to a small share of users first — 1%, then 5%, 20%, everyone — and checking crash and error rates before each step, so a bad release reaches a few people instead of all of them. It limits how many a bad release reaches, not whether it reaches them: on the app stores a halted rollout does not take the update back from those who already have it.

the rehearsal environment

A copy of production that changes are tried on before real users meet them. How much it proves depends entirely on how closely it matches production — a staging environment with a tenth of the data, no real traffic and a different config demonstrates that the code starts, and not much more.

anyone the outcome affects

Anyone whose work or results are affected by what is being built, whether or not they can decide anything about it. The distinction that matters in practice is between those who are consulted and those who can say no.

relative size, not hours

A unit for estimating the relative size of backlog items — an 8 is roughly twice a 5 — deliberately not tied to hours. They are useful for one team’s planning and nothing else: turned into a target or compared across teams, they inflate instead of measuring.

Explained in full: /management/leadership/estimation

an answer constrained to a schema

A provider feature that forces a model response to fit a schema you supply, instead of asking for JSON in the prompt and hoping. It removes parsing failures rather than reducing them, and the difference matters: a request phrased politely in prose fails on the day the model decides to apologise first.

Explained in full: /development/ai-llm/prompt-engineering

money already spent and gone

Money already spent that no decision can recover. A decision to carry on should compare only the cost still to come with the alternatives; letting what is already spent argue for finishing is the sunk-cost fallacy, and it keeps failing projects alive for years.

Explained in full: /management/frameworks/prince2

the standing instructions

The part of a prompt carrying the role and the rules, sent on every call and normally not shown to the user. It is not a secret: it sits in the same window as everything else and has been extracted from production systems by asking, so anything genuinely confidential belongs outside it.

Explained in full: /development/ai-llm/prompt-engineering

sizes XS–XL instead of numbers

A coarse way of estimating that sorts items into classes — XS, S, M, L, XL — instead of giving them numbers, used for roadmaps, epics and first conversations about cost. It works only if each size is agreed to mean a range of real time; added up as if the sizes were numbers, it produces a precise-looking total that means nothing.

Explained in full: /management/leadership/estimation

what decides pass or fail

Whatever decides whether a program’s output is correct — usually an expected value written beside the input. When none can be written down, as with generated text, the oracle can be a contract the output must satisfy, a relation between two outputs, a grader or a person.

Explained in full: /qa/ai-testing/testing-llm-products

more small tests than big ones

A model of a test suite with many fast, narrow tests at the bottom, fewer that test services in the middle, and few end-to-end tests at the top. It is an argument about cost, not a quota: the top layer is small because each test there is the slowest and most expensive one a team owns.

Explained in full: /qa/types-of-testing/e2e-testing

an attribute tests hold on to

An attribute added to markup for the sole purpose of letting tests find an element. It exists so a test does not hold on to a CSS class or a piece of visible text — both of which change for reasons that have nothing to do with behaviour.

Explained in full: /qa/automation/playwright

finished items per period

How many items a team actually finishes per week or per month. Unlike velocity it needs no estimates at all, which is exactly why it survives contact with a team that has stopped believing in story points.

Explained in full: /management/methodologies/kanban

paid for the hours spent

A contract where the client pays for the time actually worked rather than for a fixed scope, so changing direction costs money instead of a renegotiation. The risk moves to the client, which is why this model comes with more reporting and a harder conversation about what the hours bought.

share of good cases passed

The share of real negatives — good answers, healthy cases — that a test, a classifier or a model judge correctly lets pass. A TNR of 91% means about one good case in eleven is flagged by mistake; a high TNR on its own says nothing, since passing everything scores 100%.

a marker that says “deleted”

A marker that a distributed or append-only store writes on delete instead of removing the data, so that every copy learns the record is gone. Reads must step over tombstones until a later cleanup removes them, which is why heavy deleting makes such stores slower rather than smaller.

Explained in full: /development/databases/nosql

the model asking code to run

A model response that, instead of text, names one of the functions you described to it and supplies arguments; your code runs it and hands the result back. The arguments are untrusted input and are validated like any request body — a model that has read an injected instruction produces a well-formed, entirely wrong call.

Explained in full: /development/ai-llm/ai-agents

security chip on the board

A standard security chip on a computer’s board that holds keys it will not export, records what the device booted, and can release a secret only to that measured state. It raises the cost of pulling a key out of a captured device; it does not make it impossible for someone with a laboratory and time.

share of real failures caught

The share of real positives a test, a classifier or a model judge actually catches — the same quantity as recall. A TPR of 80% means one real failure in five gets through; read it beside the TNR, because a judge that flags nothing has a perfect TNR and a TPR of zero.

everyone merges into one branch daily

A way of working in which every developer merges small changes into one shared branch at least once a day, hiding unfinished work behind feature flags rather than in long-lived branches. It needs a test suite that answers in minutes and is trusted; without one it only merges breakages faster.

Explained in full: /management/release-process/git-branching-strategy

JavaScript with type checking

JavaScript plus a description of what each function takes and returns, checked in the editor before anything runs. It never reaches the browser — it is compiled back into plain JavaScript first, so the types are a development-time tool and nothing more.

Explained in full: /development/frontend/javascript

what the user sees

Everything the user sees and operates: screens, buttons, fields, states. UI is how the interaction looks; whether the interaction makes sense in the first place is a UX question, and the two get confused constantly.

what the spec leaves open

Behaviour a language or specification deliberately leaves undefined: the program may crash, appear to work or do something else entirely, and the outcome can change with the compiler version or the platform. In C, C++ and unsafe Rust it is what a memory bug turns into, because the compiler is allowed to assume it never happens.

a need told from the user’s side

A short description of something a user needs and why, usually "As a …, I want …, so that …", written as a promise of a conversation rather than a specification. Its weakness is its strength: without acceptance criteria agreed in that conversation, two people will build two different things from one card.

Explained in full: /management/decomposition/user-stories

the world’s reference time

The time standard that clocks and logs are normally kept in, with no time zones and no daylight saving. It inserts leap seconds to stay close to the Earth’s rotation, which is why GPS time, which does not, now runs 18 seconds ahead of it.

a 128-bit id made anywhere

A 128-bit identifier that any machine can generate without asking a central counter, with practically no chance of two colliding. Version 4 is random, which keeps it unguessable but scatters database inserts; version 7 starts with a timestamp, so new ids sort in the order they were created.

how much fits in a sprint

How much a team actually completes in a sprint, averaged over several. It is a planning aid for that one team and nothing else — comparing the velocity of two teams, or setting it as a target, reliably produces inflated estimates rather than more work.

Explained in full: /management/methodologies/scrum

the visible part of the page

The rectangle of the browser window the page is actually drawn in — the screen minus the browser’s own bars. On a phone it changes size as the address bar slides away, which is why a height of 100vh can be taller than what the reader sees.

a front-end build tool

A build tool and development server for front-end code, started in 2020 by Vue’s author and now used with most frameworks. In development it serves your source files to the browser almost as they are, so it starts in a moment; for production it bundles and minifies them.

encrypted tunnel into a network

An encrypted tunnel that lets a remote machine join a private network as if it were inside it. The appliance at the end of the tunnel is a door into everything behind it, so its configuration is as sensitive as any password.

the project’s scope as a tree

A tree of everything a project will deliver, broken down until each piece is small enough to estimate and give to one owner — and, by definition, nothing the project will not deliver. Its children must add up to exactly their parent, which is what makes it a scope boundary rather than a task list.

Explained in full: /management/decomposition/work-breakdown-structure

the accessibility standard

The W3C’s standard for making web content usable by people with disabilities, written as testable success criteria at three levels, A, AA and AAA. Level AA is what laws and contracts usually point at, and meeting it on paper is not the same as a blind person being able to finish your checkout.

an HTTP call saying something happened

An HTTP request one system sends to a URL you registered, to tell you that something happened — a payment succeeded, an order shipped — so you do not have to keep asking. Delivery is usually at least once and sometimes out of order, so the receiver must cope with the same event arriving twice.

Explained in full: /development/architecture/api-design

Safari’s browser engine

The open-source browser engine behind Safari. A page that works in Chrome can still break in WebKit, which is why test suites run their browser journeys in it too — Playwright ships its own WebKit build for exactly that.

a connection kept open both ways

A connection that stays open in both directions: unlike HTTP, the server can send a message on its own without waiting to be asked. Chats and live feeds are built on it, and so is most of what looks like the page updating by itself.

how much is started at once

The amount of work started but not finished. Capping it is the central move in Kanban: the bottleneck becomes visible instead of hidden, and things reach done sooner precisely because fewer are begun.

Explained in full: /management/methodologies/kanban

two valid checks, one broken rule

A concurrency anomaly in which two transactions read the same data, each makes a change that is valid on its own, and together they break a rule — two doctors going off call because each saw the other still on duty. It survives every isolation level below serializable, because neither transaction overwrites the other.

Explained in full: /development/databases/sql

cost of delay divided by job size

A way of ordering a backlog: divide each item’s cost of delay by its size and do the highest ratio first, so small urgent items overtake large ones. Donald Reinertsen’s original divides a cost in money by a duration; SAFe’s version adds three relative scores and divides by a size estimate, which makes it a structured conversation rather than a precise calculation.

Explained in full: /management/methodologies/safe