Software development jargon decoded: repos, builds, releases and sprints

Project updates from a software team can read like a different language: “we merged the PR, the pipeline is green, and we will cut a release to staging before the sprint ends.” Behind the jargon is a simple, sensible routine for building software safely with several people. Once you see the routine, the words make sense.

This article follows a small change from an idea to a live release, naming the pieces on the way.

Keeping the history: version control

• Version control. A system that records every change to the code, who made it and why, so that nothing is lost and mistakes can be undone. Git is the most widely used.
• Repository (repo). The project’s folder, together with its entire history.
• Commit. A saved set of changes, with a short message describing it.
• Branch. A separate line of work, so that someone can try something without disturbing the main version.
• Merge. Combining a branch back into the main one.
• Pull request (PR). A proposal to merge a branch, which colleagues review before it is accepted.
• Conflict. When two people changed the same lines and the system needs a person to decide.
• Fork. A personal copy of someone else’s repository.

Writing the code

• Library. A bundle of ready-made code for a particular job, such as drawing charts.
• Framework. A larger structure that tells you how to organise your whole application.
• Dependency. Another piece of software that yours relies on. Updating or losing one can break your project.
• Open source. Code that is published for anyone to read, use and often modify, under a licence.
• Refactoring. Tidying the inside of the code without changing what it does.
• Technical debt. The accumulated cost of shortcuts. Like financial debt, it is fine in moderation and ruinous if ignored.
• Legacy system. Old software that still matters, and is hard to change.

Checking the code

• Bug. A mistake in the software.
• Testing. Running the software to see whether it does what it should.
• Unit test. A small, automatic check of one piece. Integration tests check that pieces work together, and end-to-end tests simulate a user.
• QA (quality assurance). The practice of finding problems before users do.
• Code review. A colleague reading your changes before they are accepted.
• Regression. Something that used to work and broke after a change.
• Linting. Automatic checks for style and common mistakes.

The assembly line: building and delivering

• Build. Turning source code into something that can be run.
• CI (continuous integration). Automatically building and testing the code every time someone makes a change.
• CD (continuous delivery or deployment). Automatically preparing, or even releasing, tested code.
• Pipeline. The automated sequence of steps from change to release.
• “The pipeline is green”. All the automatic checks have passed. “Red” means something failed.
• Artifact. The built, packaged output of a pipeline.
• Container (such as Docker). A sealed package of software and everything it needs, so that it runs the same everywhere.

Environments and releases

• Development (dev). Where programmers work and experiment.
• Staging (or test). A close copy of the live system, used as a rehearsal.
• Production (prod). The real, live system that users depend on.
• Deployment. Putting a version into an environment.
• Release. A version made available to users. Version numbers such as 2.4.1 usually signal how big the change is.
• Rollback. Returning to the previous version if the new one causes problems.
• Hotfix. An urgent fix released outside the normal schedule.
• Feature flag. A switch that turns a new feature on for some people, or off, without a new release.
• Downtime and maintenance window. The planned period when a system is unavailable for work.

How teams organise the work

• Agile. A way of working in short cycles, with frequent feedback, instead of one long plan.
• Sprint. A fixed work period, often one to two weeks, with an agreed goal.
• Backlog. The ordered list of work that is waiting.
• User story. A short description of a need from a user’s point of view: “As a field officer, I want to see my villages on a map”.
• Stand-up. A very short daily meeting to share progress and blockers.
• Retrospective. A meeting at the end of a sprint to discuss what went well and what to change.
• Scrum and Kanban. Two popular ways of organising agile work.
• MVP, PoC and prototype. Increasingly complete early versions, used to learn before building fully.
• Roadmap. The longer-term plan of what will be built.

Words that mean different things to different people

• “Done”. Written, tested, reviewed, deployed and documented, or just written? Agree a definition of done.
• “Quick fix”. Often a shortcut that creates technical debt.
• “It works on my machine”. It runs for the developer, and may fail elsewhere. It is the reason environments and containers exist.
• “We will refactor later”. It may never happen. Ask when.

Questions to ask your software team

• Where is the code kept, and who owns that account?
• How are changes reviewed and tested before they reach users?
• How often can we release, and how do we undo a bad one?
• What does “done” mean for this project?
• How much technical debt do we carry, and what is the plan for it?
• Is it documented well enough that someone new could take over?

Frequently asked questions

What is the difference between a library and a framework?

You call a library when you need it. A framework calls your code, and sets the structure. A library is a tool, and a framework is a template.

Why are releases not instant?

Because testing, review and careful rollout protect users from mistakes. Automation makes frequent, safe releases possible.

Is agile just a way to avoid planning?

No. Done well, it plans continuously, in small steps, and adapts to what is learned. Done badly, it can become disorganised.

What is DevOps?

A set of practices that bring development and operations together, so that software is built, released and run as one smooth process.

Software jargon describes how people keep a complicated thing under control. When you hear a word, ask what problem it solves: remembering, checking, packaging, releasing or organising. The word will nearly always map to one of them.