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:

Scrum​

Agile development methodology.

See:

Backlog Refinement​

"Backlog refinement is a process by which team members revise and prioritize a backlog for future sprints.[31] It can be done as a separate stage done before the beginning of a new sprint or as a continuous process that team members work on by themselves. Backlog refinement can include the breaking down of large tasks into smaller and clearer ones, the clarification of success criteria, and the revision of changing priorities and returns. " - [Scrum, Wikipedia]https://en.wikipedia.org/wiki/Scrum_(software_development)#Backlog_refinement

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:

Beta Test​

Beta testing is the process of testing an unreleased piece of software with a portion of its intended audience.

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:

Dog-Fooding​

Eating your own dog food is the process by which you use your product or service internally in order to get more feedback about how well it works.

See:

Feature Toggle​

A condition within the code enables or disables a feature during runtime, perhaps for a certain group of users.

See: