Library / Glossary / The craft glossary
Software development for non-engineers glossary
46 terms from R11, Software development for non-engineers — 22 defined in the guide itself and 24 more from the field around it. Every term the guide teaches links to the slide that teaches it.
R11 · How to build
Software development for non-engineers
What is actually happening when engineers build?
Every term below is defined in the words of software development for non-engineers, guide R11 of craft guides for educational technologists, and opens the guide at the slide where it is taught. 24 of the 46 are the field’s vocabulary rather than the guide’s own: words a reader will meet around this subject, defined here because the guide assumes them. 2 terms are also defined by another guide in the series; where the two differ, both wordings are given. The whole craft glossary holds all of them together.
| Term | Definition | Referred to in | Read further |
|---|---|---|---|
| A | |||
| API | Application programming interface: the published set of requests a system will accept from other software. |
| |
| B | |||
| Back end | The servers and databases that hold a system's rules and records, out of the user's sight. |
| |
| Black-box monitoring | Checking a live system from the outside, as a user would, for example with an automated login. |
| |
| Blameless postmortem | A review of an incident that looks for contributing causes without blaming individuals (Beyer et al., 2016). |
| |
| Branch | A separate line of work in version control, where changes can be made and tested without affecting the main line until they are merged back in. |
|
|
| Brooks's law | Adding people to a late software project makes it later, because new people must be trained and must coordinate with everyone else (Brooks, 1975). |
| |
| C | |||
| Cache | A store of recently fetched or computed results kept close to where they are needed, so that repeat requests are answered faster and put less load on the system behind it. |
|
|
| Capacity planning | Forecasting the demand a system will face, including its predictable peaks, and making sure enough computing resource is in place, tested and paid for before that demand arrives. |
|
|
| Client–server model | The arrangement behind most web software: a client, such as a browser or app, sends requests, and a server holding the shared data and rules sends back responses. |
|
|
| Cloud computing | Rented computing resources that can be added or released quickly with little effort (Mell & Grance, 2011). |
| |
| Code review | The reading of one developer's changes by another before they are merged, to find defects, improve the code and spread knowledge of it across the team. |
|
|
| Conway's law | The observation that a system's structure comes to mirror the communication structure of the organisation that built it: three contracted teams tend to produce a system in three parts. |
|
|
| D | |||
| Database | The part of a system that stores records, such as students, classes and marks. |
| |
| Domain Name System (DNS) | The internet's directory, which turns a name such as a school's web address into the numeric address of the server to contact. A DNS fault makes a working service unreachable. |
|
|
| E | |||
| End-to-end test | An automated test that drives the whole running system as a user would, for example by logging in through a browser and submitting work. Slow and fragile, so kept few. |
|
|
| Error budget | The amount of failure a reliability target allows over a period; one minus the target. R12 The amount of unreliability a service may have in a period before releases pause (Beyer et al., 2016). |
| |
| F | |||
| Four golden signals | Four signals worth watching on any live service: latency, traffic, errors and saturation (Beyer et al., 2016). |
| |
| Front end | The part of a system that runs in the browser or app and that users see and touch. R03 The early, uncertain stage of design where a team decides what to design, if anything (Sanders & Stappers, 2008). |
| |
| G | |||
| Git | The most widely used version control system. Each developer holds a full copy of the project's history and exchanges changes with a shared copy, usually on a hosting service. |
|
|
| I | |||
| Integration test | An automated test that checks several parts of a system working together, such as the code and its database, rather than one unit on its own. |
|
|
| L | |||
| Latency | The delay between sending a request and receiving the response. Users feel it as slowness, and it usually climbs steeply as a system nears its capacity. |
|
|
| Legacy system | An older system that an organisation still depends on but finds hard to change, because its technology is outdated, its authors have left or it lacks tests and documentation. |
| |
| Load balancer | A component that spreads incoming requests across several servers, so that no single one is overwhelmed and a failed server can be taken out of use. |
|
|
| Load test | A test that sends a system realistic or higher-than-expected traffic to see how it copes and where it breaks. |
| |
| M | |||
| Microservices | An architecture that splits a system into small services, each run and deployed separately and talking over a network. The alternative, one application deployed as a whole, is called a monolith. |
|
|
| Migration | Moving existing data or systems into a new structure or location. | ||
| N | |||
| Non-functional requirement | A requirement about how well a system works, such as speed, reliability or security, rather than what it does. |
| |
| O | |||
| Open-source software | Software whose source code is published under a licence that lets anyone use, study, change and redistribute it. Most modern systems are built largely from open-source components. |
|
|
| P | |||
| Product quality model | The international model of nine characteristics of software quality, among them functional suitability, reliability, security, maintainability and safety (ISO/IEC, 2023). |
| |
| Pull request | A proposal to merge a set of changes from a branch into the main code, which teammates can discuss, review and test before it is accepted. Some tools call it a merge request. |
|
|
| R | |||
| Refactoring | Improving the structure of existing code without changing what it does; a common way to repay technical debt. |
| |
| Regression test | A test re-run after every change to confirm that features which used to work still do. A regression is a fault introduced into something that previously worked. |
|
|
| REST | Representational state transfer: the architectural style of the web, in which clients act on named resources through a small uniform set of requests. Most web APIs today are described as RESTful. |
|
|
| Rising cost of defects | The popular claim that a defect costs up to 100 times more to fix after release; the original data were thin, and 171 projects showed no consistent effect (Menzies et al., 2017). |
| |
| S | |||
| Scalability | A system's ability to handle more users, data or requests by adding resources, without being redesigned. Scaling up uses a bigger machine; scaling out uses more machines. |
|
|
| Service level indicator (SLI) | A defined measure of some aspect of a service, such as the share of logins that succeed. |
| |
| Service level objective (SLO) | A target value for a service level indicator, such as 99.9% of logins succeeding each month. |
| |
| Single point of failure | A part of a system with no backup, whose failure stops the whole service. Reliable designs remove them by duplicating components. |
|
|
| Software architecture | The main parts of a system, how they connect, and the early decisions about them that are costly to change later. It largely decides qualities such as speed, reliability and ease of change. |
|
|
| Software as a service (SaaS) | Software that the supplier runs on its own cloud infrastructure and customers use over the internet, usually by subscription, with nothing to install or upgrade themselves. |
|
|
| T | |||
| Technical debt | The future cost of a shortcut taken now, paid as extra effort on every later change until it is repaid (Cunningham, 1992). |
| |
| Technical debt quadrant | A sorting of technical debt two ways, reckless or prudent and deliberate or inadvertent; the useful distinction is between prudent and reckless debt (Fowler, 2009). |
| |
| Test pyramid | A guide to balancing automated tests: many small unit tests, fewer broad ones (Fowler, 2012). |
| |
| U | |||
| Unit test | An automated check of one small piece of code, usually run in seconds on every change. |
| |
| User acceptance testing (UAT) | Testing by the customer or the intended users, before go-live, of whether a system does what they need in their own setting. Often a formal condition of accepting and paying for delivered work. |
|
|
| V | |||
| Version control | A system that records every change to a set of files, who made it and why, so that earlier versions can be recovered and several people can work on the same code. |
|
|
No term matches. Try fewer letters.
Nearby