Top 100 Vocabulary for Adults | Software & Technology Professionals
Technology vocabulary is the language of systems that change quickly but still need to be understood clearly. Software professionals move between user need, architecture, code, data, security, deployment, reliability and trade-offs—often across teams that do not share the same technical depth.
This profession-specific flagship belongs to the eduKate Adult Vocabulary for Professionals system and connects to Engineers, Problem Solving and Reports, Memos & Briefings.
The Four Banks
Systems & Architecture: system, service, application, platform, architecture, component, module, dependency, interface, API, protocol, database, schema, state, stateless, distributed, synchronous, asynchronous, latency, throughput, availability, scalability, redundancy, resilience, observability.
Development & Delivery: requirement, user story, backlog, sprint, iteration, repository, branch, commit, merge, build, test, unit test, integration test, regression, bug, defect, release, deployment, environment, configuration, version, rollback, automation, CI/CD, technical debt.
Security, Data & Reliability: authentication, authorisation, encryption, vulnerability, exploit, patch, threat, risk, incident, breach, access control, least privilege, backup, recovery, logging, monitoring, alert, metric, SLO, SLA, error budget, data quality, privacy, compliance, audit.
Product & Communication: product, feature, user, stakeholder, roadmap, priority, trade-off, scope, estimate, feasibility, usability, accessibility, experiment, metric, adoption, retention, conversion, feedback, root cause, postmortem, documentation, rationale, decision, owner, handover.
Top 100 Software & Technology Vocabulary: Working Meanings
| # | Word | Professional meaning |
|---|---|---|
| 1 | System | A set of interacting software, hardware or human components. |
| 2 | Service | A software capability exposed for use by other systems or users. |
| 3 | Application | Software designed to perform user-facing or business functions. |
| 4 | Platform | A foundation on which applications or services are built or operated. |
| 5 | Architecture | The high-level structure and relationships of a technology system. |
| 6 | Component | A distinct functional part of a larger system. |
| 7 | Module | A defined unit of software responsibility or implementation. |
| 8 | Dependency | A system, library or service on which another component relies. |
| 9 | Interface | A boundary through which systems or components interact. |
| 10 | API | An application programming interface defining how software components communicate. |
| 11 | Protocol | A defined set of rules for communication between systems. |
| 12 | Database | A structured system for storing and retrieving data. |
| 13 | Schema | The defined structure and relationships of data. |
| 14 | State | Stored information representing a system’s current condition. |
| 15 | Stateless | Designed so each request can be handled without relying on stored session state. |
| 16 | Distributed | Operating across multiple networked machines or services. |
| 17 | Synchronous | Requiring one operation to wait for another to complete. |
| 18 | Asynchronous | Allowing work to proceed without immediate completion of another operation. |
| 19 | Latency | The delay between request and response or action and result. |
| 20 | Throughput | The amount of work a system completes over time. |
| 21 | Availability | The proportion of time a system is usable as intended. |
| 22 | Scalability | Ability to handle increased load without disproportionate degradation. |
| 23 | Redundancy | Additional components or capacity intended to preserve service after failure. |
| 24 | Resilience | Ability to absorb disruption and recover function. |
| 25 | Observability | The ability to infer internal system state from outputs such as logs, metrics and traces. |
| 26 | Requirement | A condition the software must satisfy. |
| 27 | User story | A concise description of a user need or desired outcome. |
| 28 | Backlog | An ordered list of work awaiting consideration or delivery. |
| 29 | Sprint | A short, time-boxed period of focused delivery in some agile methods. |
| 30 | Iteration | A repeated cycle of build, test and improvement. |
| 31 | Repository | A managed location for source code and related history. |
| 32 | Branch | A separate line of development in version control. |
| 33 | Commit | A recorded set of changes in version control. |
| 34 | Merge | Combining changes from different branches. |
| 35 | Build | The process of transforming source code into runnable or deployable software. |
| 36 | Test | A structured check of software behaviour. |
| 37 | Unit test | A test focused on a small unit of code. |
| 38 | Integration test | A test examining interaction among components or services. |
| 39 | Regression | A previously working behaviour that breaks after change. |
| 40 | Bug | An error or unintended behaviour in software. |
| 41 | Defect | A failure to meet a specified requirement. |
| 42 | Release | A defined version made available for use. |
| 43 | Deployment | The process of placing software into an environment for use. |
| 44 | Environment | A defined operating context such as development, testing or production. |
| 45 | Configuration | Settings controlling system behaviour without necessarily changing code. |
| 46 | Version | A distinct identified state of software. |
| 47 | Rollback | Reverting to an earlier known version after a problematic change. |
| 48 | Automation | Use of software to perform repeatable tasks with reduced manual intervention. |
| 49 | CI/CD | Continuous integration and delivery/deployment practices for frequent, controlled software change. |
| 50 | Technical debt | Future cost created by expedient technical choices that make later change harder. |
| 51 | Authentication | Verification of identity. |
| 52 | Authorisation | Determination of what an authenticated identity is allowed to do. |
| 53 | Encryption | Transformation of data to protect it from unauthorised access. |
| 54 | Vulnerability | A weakness that may be exploited to cause harm. |
| 55 | Exploit | A method or code using a vulnerability to achieve unintended behaviour. |
| 56 | Patch | A software change intended to correct a defect or vulnerability. |
| 57 | Threat | A potential source of harm to systems or data. |
| 58 | Risk | Uncertainty involving potential harm or failure. |
| 59 | Incident | An event requiring operational or security response. |
| 60 | Breach | Unauthorised access, disclosure or compromise of protected information or systems. |
| 61 | Access control | Rules and mechanisms governing who can access resources. |
| 62 | Least privilege | Granting only the minimum access necessary to perform a task. |
| 63 | Backup | A recoverable copy of data or system state. |
| 64 | Recovery | Restoration of service or data after failure. |
| 65 | Logging | Recording system events for diagnosis, security or audit. |
| 66 | Monitoring | Ongoing observation of system performance and health. |
| 67 | Alert | A notification that a defined condition requires attention. |
| 68 | Metric | A defined quantitative measure of system or product behaviour. |
| 69 | SLO | A service level objective defining a target level of service performance. |
| 70 | SLA | A service level agreement defining formal service commitments between parties. |
| 71 | Error budget | The amount of unreliability permitted while still meeting a service objective. |
| 72 | Data quality | The degree to which data is accurate, complete, timely and suitable for use. |
| 73 | Privacy | Protection and appropriate handling of personal or sensitive information. |
| 74 | Compliance | Conformity with applicable requirements or standards. |
| 75 | Audit | A structured review of systems, controls or records. |
| 76 | Product | A technology offering designed to create user or business value. |
| 77 | Feature | A defined product capability. |
| 78 | User | A person interacting with the product or system. |
| 79 | Stakeholder | A party affected by or influencing the technology decision. |
| 80 | Roadmap | A sequenced view of intended product or technical development. |
| 81 | Priority | A work item deliberately given precedence. |
| 82 | Trade-off | A gain in one dimension requiring cost in another. |
| 83 | Scope | The boundaries of work included. |
| 84 | Estimate | An approximate judgement of effort, cost or duration. |
| 85 | Feasibility | Whether a technical approach can work within constraints. |
| 86 | Usability | Ease and effectiveness with which intended users can use the product. |
| 87 | Accessibility | The degree to which people with different abilities can use a product. |
| 88 | Experiment | A structured test designed to reduce product or technical uncertainty. |
| 89 | Adoption | Actual use of a product or feature. |
| 90 | Retention | Continued use over time. |
| 91 | Conversion | Movement from one user stage to another desired action. |
| 92 | Feedback | Information from users or systems used to improve decisions. |
| 93 | Root cause | A fundamental causal factor, where such a factor can reasonably be identified. |
| 94 | Postmortem | A structured review of an incident intended to learn and reduce recurrence. |
| 95 | Documentation | Written information explaining system design, behaviour or operation. |
| 96 | Rationale | The reasoning behind a technical or product decision. |
| 97 | Decision | A settled technical or product choice. |
| 98 | Owner | The person charged with an action, system or outcome. |
| 99 | Handover | Transfer of knowledge and responsibility. |
| 100 | Maintainability | Ease with which software can be understood, changed and repaired over time. |
Reliability vs Availability
A system can be available most of the time yet unreliable in important edge cases. It can also be highly reliable when running but unavailable too often. Technology teams need language precise enough to say which problem actually exists.
Technical Debt Is a Trade-off, Not a Moral Failure
Sometimes a faster implementation is rational. The problem is invisible debt: shortcuts whose future cost is unknown, unowned or repeatedly deferred. Name the debt, consequence and repayment trigger.
Scenario: Production Incident
State impact, affected users, current system state, mitigation, uncertainty and next update time. During the incident, stabilise first. Afterward, investigate contributing factors without turning the postmortem into blame.
Seven-Day Technology Vocabulary Plan
| Day | Practice |
|---|---|
| 1 | Map one system into components, interfaces and dependencies. |
| 2 | Separate latency, throughput, availability and scalability. |
| 3 | Practise build-test-release-deploy language. |
| 4 | Map one security risk through threat, vulnerability and control. |
| 5 | Write a concise incident update for a non-technical stakeholder. |
| 6 | Recall 75+ terms by technology function. |
| 7 | Write a one-page technical decision record with trade-offs. |
Continue the Profession Wing
Conclusion
Technology vocabulary lets professionals describe complex systems without making them mysterious. The best language identifies dependencies, trade-offs, risk, evidence and ownership clearly enough that teams can change the system without losing control of it.