Skip to main content

Glossary

Abstraction (Using)

"An abstraction" is the outcome of this process—a concept that acts as a common noun for all subordinate concepts and connects any related concepts as a group, field, or category.[1]

Changing abstractions is often known as refactoring. Removing unnecessary or outdated abstractions is often called simplification.

See:

Standardization

Given multiple, different, competing abstractions, an effort to pick a single one and try to persuade everyone to adopt it.

See:

Modularisation

Breaking code up into different subsystems with limited, often well-defined interfaces to interact with them.

See:

Dependency (Using a)

Making use of libraries, services or languages to solve a particular programming challenge.

See:

Process Introduction

The attempt to formalize the interface for accessing a scarce or controlled resource.

See:

Automation

Converting a manual Process into an automatic, computer-controlled one.

See:

Compilation

Converting source code into executable binary code. Also involves checking the consistency and internal logic of the source code.

See:

Communication

“The fundamental problem of communication is that of reproducing at one point, either exactly or approximately, a message selected at another point.”

Includes the sub-actions or motivation, composition, encoding, transmission, reception, decoding, interpretation and reconciliation.

See:

Translation

Converting from one communication protocol to another. Can be called a bridge.

See:

Blaming

The act of shifting burden of responsibility onto someone else.

See: Risk First Diagrams

Requirements Capture

Talking to stakeholders in order to understand what issues they need a piece of software to solve. Often seen as an important step in building an Internal Model of a problem area before tackling a Specification.

Also known as market research.

See:

Environmental Scanning

Understanding the operational environment of a system in order to anticipate future problems.

See:

Market Segmentation

A process by which you divide the addressable market of users for a piece of software into different types or personas in order that you can tackle the requirements of a single group in isolation.

See:

Innovation

The process of evolving a product to better manage existing or newly discovered Feature Risk. Also called evolution (often when talking about ecosystems or organisms), extension (when applied to standards or protocols) or improvement.

See:

Marketing

The process of trying to make your product visible and attractive to potential customers by communicating the benefits to them.

The strategic functions involved in identifying and appealing to particular groups of consumers, often including activities such as advertising, branding, pricing, and sales.

See:

Specification

Writing a specification to describe how a piece of functionality should best mitigate Feature Risk. Also known as design.

See:

Redundancy / Horizontal Scaling

Introducing duplication of workers or other resources in order to mitigate single-points-of-failure.

See:

Reserving (or Buffering)

Creating reserves or buffers of a scarce resource in order to deal with peaks in demand that would deplete the resource.

See:

Graceful Degredation

Handing lack of a scarce resource by failing in a tolerable way.

See:

Pools / Queues

A way of ensuring orderly consumption of scarce resources.

See:

Product Development

Mitigating Feature Risk by adding code to a project. Can often be called coding or implementation.

See: Development Process

Integration

Combining different versions of a codebase together to check for consistency. Also called Continuous Integration.

See:

User Acceptance Testing (UAT)

Completing a Feedback Loop in order to ascertain whether Feature Risk has been correctly addressed by new features. Also called verification, user feedback or manual testing.

See:

Release

The act of moving in-development software to being in production, so that clients can make use of it.

See:

Testing

See:

Security Testing

Performing tests to evaluate the security of a given system. May include penetration testing, for example.

See:

Experimentation

Improving your internal model by testing (or playing with) components of the real world context. For example, building a spike solution.

See:

Unit Testing

Writing extra (test) code in the project which can automatically check that the (main, business logic) code works correctly. Used to mitigate Regression Risk and Implementation Risk in a short-cycle feedback loop.

See:

Operation / Maintenance

Maintaining running software in production so that it is available for clients to use.

See:

Sign-Off

The act of introducing a human-controlled approval step into a Process in order to mitigate Operational Risks.

See:

Fund Raising / Borrowing

Dealing with a resource shortage by borrowing the resource from another agent temporarily.

See:

Monitoring

Keeping track on systems (agents) to ensure they are operating correctly. Also includes detecting failure and if done periodically (by another party) audit.

See:

Security

Within a given context, limiting the actions of agents to perform certain privileged tasks.

See:

Accountability (Assigning)

Making an individual or team responsible for some given goal / risk. Perhaps involving some skin in the game. Compare individual responsibility with collective responsibility.

See:

Controlling

Keeping a process performing within some acceptable parameters to achieve a goal or mitigate a risk.

See:

Planning

Using an Internal Model to project forward to some desirable future outcome, and proposing a route across the imagined risk landscape to get there.

various types of planning exist such supply chain management, dependency management, project planning, just in time or capacity planning.

See: