Patterns and Practices

Anticorruption Layer Improve

An anticorruption layer is a logical layer that provides a stable interface to (potentially) volatile software components. As long as this interface remains untouched developers can implement changes or even replace their own or third-party software without affecting the clients of this interface.

Architectural Understanding Cross-cutting

Document relevant structures, concepts, decisions, interfaces etc. of the system to locate issues, risks and opportunities for improvement.

Architecture Backlog stub Improve

Keep a prioritized list of improvement tasks (remedies) with their as a backlog, parallel to the (regular) feature backlog.

Assertions stub Improve

Use assertions to verify preconditions and to make a program fail early when something goes fundamentally wrong.

ATAM Analyze

Apply the ATAM method to evaluate the software architecture regarding its compliance with quality goals.

Automated Tests stub Improve

Introduce automated tests to verify correctness or runtime behavior. Unit-, integration-, acceptance-, load- or database-tests are well-known specialisations of this.

Big Bang Approach Improve

Approach to replace an old system with a new system with one big bang deployment.

Branch for Improvement stub Improve

Introduce distinct branches in your version control system to reflect improvements.

Bulkhead stub Improve

Can be placed between two systems to avoid the propagation of faults from one system to the other system ([Nygard07], p. 119ff.).

Bus Factor Analyze

Improve the structure of a system or its documentation so that the organisation is not at risk if certain key people leave.

Butterfly Methodology Improve

Data migration method without the need of gateways. Enables zero-downtime migrations by working with temporary data stores.

Capture Quality Requirements Analyze

Make the specific quality requirements of a system explicit.

Change by Copy stub Improve

Isolate competing change necessity by copying and allowing the copies to evolve independently. Also known as Change via Split.

Change by Extension stub Improve

Enable efficient change by creating new components instead of modifying existing ones.

Change-by-Abstraction Refactoring Improve

Incrementally replace part of the system with a new implementation.

Change-by-Split Approach Improve

Maintain and evolve a few smaller systems, instead of one big monolith. Reduce time-to-market, work in smaller teams that individually become more focussed.

Chicken-Little Approach Improve

Software-Migration with incremental steps to avoid or reduce the risks coming along with the Big Bang approach.

Collect Issues Cross-cutting

Keep a list of problems, issues and risks. Regularly match those to your collection of possible remedies.

Collect Opportunities for Improvement Cross-cutting

Keep a list of possible and potential measures, remedies, tactics, strategies for improvements. Regularly match those to your collection of issues.

Composite Database Approach Improve

Combination of Database-First and Database-Last. Beside a forward- and reverse-gateway, there is a need for a transaction-coordinator.

Context Analysis Analyze

Analyse external interfaces for risk, technology, business value and other factors.

Data Analysis Analyze

Analyze and inspect the data created and manipulated by the system for its content, structure, quantity and size.

Database First Approach Improve

Do a Big-Bang migration of the database, incrementally implement new applications and interfaces and connect the legacy system to the new database by forward gateways.

Database Last Approach Improve

Keep the existing database for a limited time, incrementally implement new applications and interfaces and connect them to the legacy database by reverse gateways.

Debugging Analyze

Identify the source of an error (bug) or misbehavior by observing the flow of execution of a program in detail.

Deprecate Obsolete Parts stub Improve

Actively mark parts in software that aren’t needed anymore and communicate to your consumers or customers, that you will remove specific functionality in the future.

Development Process Analysis Analyze

Analyse and inspect the development process (as documented or described by stakeholders) for appropriateness, problems or problem-areas.

Docs-as-Code Improve

Docs-As-Code is a documentation approach that raises developer-related documentation to the same importance as source code.

Document Problems stub Cross-cutting

See Improvement Backlog.

Documentation Analysis Analyze

Analyse existing documentation for availability, correctness, actuality, problems or problem-areas.

Estimate Feature Value Evaluate

Estimate the (monetary) value of a given feature, so you can compare features of the system with each other.

Estimate Improvement Cost Evaluate

Determine how much a specific improvement (a set of actions taken to eliminate or reduce a specific issue or problem) is likely to cost (in money and/or effort).

Estimate in Interval Evaluate

Estimate in intervals, giving lower and upper bounds.

Estimate Issue Cost Evaluate

Find out how much a given issue costs in units of money or effort in a period or for every occurrence.

Expect Denial Cross-cutting

Some people will oppose your findings, will whitewash or sugarcoat issues, problems or root causes. Regardless on how careful you prepared your analysis, they will try to diminish or attack your findings.

Explicit Assumption Cross-cutting

Compensate missing facts (especially requirements, goals, estimates, opinions) by explicit (usually written) assumptions about those facts.

Extract Reusable Component stub Improve

Extract code from an existing system to create a reusable component. See [SERIOUS-Refactoring], page 95.

Fail Fast Cross-cutting

Identify quality issues as early as possible and aim to fix them.

Fast Feedback Cross-cutting

Evaluate the quality of work artifacts and processes as early as possible. Enables teams to apply corrective actions or take countermeasures as early as possible.

Front-End Switch stub Improve

Route front-end requests to either new or old backend systems, depending on their nature, content-negotiation or other request criteria. This is especially helpful to support Never Change Running System.

Goals and Constraints Cross-cutting

Make the overall goals and constraints of the improvement efforts understandable to every stakeholder.

Group Improvement Actions stub Improve

Collect several improvement actions, which can or shall be applied or implemented together.

Handle If-Else Chains stub Improve

Refactor nested if-then-else structures for improved understandability. Can be seen as a specialisation of Remove Nested Control Structures.

Hierarchical Quality Model Analyze

Decompose the overall goal of “high quality” into more detailed and precise requirements, finally resulting in a tree-like structure. See ATAM and [Quality-Requirements].

Impact Analysis Cross-cutting

Determine what impact (in code, concepts, data and the organization) a specific action or issue (e.g. refactoring, recurring problem) will or might have. Identify the resultant effects on system development and operations.

Improve Code Layout stub Improve

Making code easier to read results in better understandability.

Improve Feedback from and for Stakeholders Improve

Effectively collect feedback from various stakeholders.

Improve Logging Improve

Employ sophisticated logging mechanisms such as modern logging frameworks, distributed log collection and visualization tools in order to gain more detailed information about the system during runtime with a minimal or predictable performance impact.

Improvement Backlog Cross-cutting

Collect all known issues and problems within a system or its associated processes, and make them comparable by evaluating each one.

Infrastructure Analysis Analyze

Analyze the technical infrastructure of the system, e.g. with respect to time and resource consumption or creation. Part of Runtime Analysis.

Instrument System Analyze

Find out how the system is really used and what the runtime relationships are, as well as other facts that can not be easily determined by Static Code Analysis even in situation where the system under design is largely undocumented and the architecture work thus mostly relies on assumptions, interviews and lore.

Interface Segregation Principle Improve

Reduce coupling between clients and service providers.

Introduce Boy Scout Rule Improve

Enable cross-cutting architectural improvement even if it is not feasible to change the whole codebase.

Introduce Layering stub Improve

Introduce layers within the source code to improve separation of concern. It’s common to have at least a business layer and an interface layer - the latter for both user- and programmatic interfaces. See Uncle Bob’s Clean Architecture for a short summary.

Isolate Changes stub Improve

Introduce interfaces and intra-system borders, so that changes cannot propagate to other areas.

Issue List Cross-cutting

Collect all known issues and problems within a system or its associated processes. Make the issues comparable by evaluating each one, usually using economical units like money or time.

Issue Tracker Analysis Analyze

Analyse entries from issue tracker to identify critical areas, components or stakeholders.

Keep Data, Toss Code stub Improve

A strategy to improve systems, keeping the data created with the (old) systems as foundation for a new one. Also described as Bridge-to-the-New-Town (by Wolfgang Keller). This is the opposite of Never Change Running System.

Manage Complex Client Dependencies with Facade Improve

Simplify the interaction of a client with a set of service components.

Measure Improve

Gather various metrics and visualize them on dashboards in order to make your system behavior more predictable and assumed coincidences explainable.

Migrate Data stub Improve

Transform existing data from one structure or representation into another by keeping its original intent or semantic intact.

Mikado Method stub Improve

Coordinated refactoring effort, described in the Mikado-book.

Natural Death stub Improve

Keep old system running and only retire it once all objects contained reach end of life according to their life cycle.

Never Change Running System stub Improve

To minimize risks, you should try to refrain from changes to existing (working) code - as every change inevitably introduces new risks or even bugs.

Never Rewrite Running System stub Improve

Joel Spolsky arguments, never to rewrite a system from scratch, as you will likely make many new mistake and won’t generate much added value.

Organizational Analysis Analyze

Analyse and inspect organization(s) responsible for the system.

Outside-in Interfaces stub Improve

Modularize system aligned to (existing) external interfaces.

Plan Improvements Cross-cutting

Conduct long- and short-term planning of improvement activities. Balance or align issues and improvements, considering existing goals and constraints.

Pre-Interview Questionnaire Analyze

Prior to interviewing stakeholders, present them with a written questionnaire, so they can reflect in advance.

Pre-Mortem Analyze

Identify issues that could let become the current project a huge disaster.

Qualitative Analysis Analyze

Analyze which quality goals of the system are at risk and which are met by the current implementation.

Quality-Driven Software Architecture stub Improve

Derive (technical, structural or process-related) decisions based upon detailed quality requirements. QDSA requires explicit quality requirements.

Quantitative Analysis Analyze

Measure artifacts or processes within the system, e.g. source code.

Questionnaire Analyze

Support interviews with guidance and hints for appropriate questions.

Refactoring stub Improve

Source code transformation that does not change functionality of system. See [Fowler-Refactoring].

Refactoring Plan stub Improve

The route of refactoring, as discussed within the development team. This plan should always be visible to every team member.

Remove Nested Control Structures stub Improve

Re-structure code so that deeply nested or complicated control structures are replaced by semantically identical versions. Special case of Refactoring, similar to Untangle Code. Often performed by reducing complexity and especially cyclomatic complexity. When reducing code complexity one needs to make sure we’re not exchanging inner/ method/ cyclomatic complexity by outer/ design or runtime complexity.

Report Structure Cross-cutting

A generic structure for written audit or review reports, usually following an Analyze phase.

Requirements Analysis Analyze

Analyze and document (current) requirements: required features and required constraints

Root Cause Analysis Analyze

Explicitly differentiate between symptom and cause: identify root causes of symptoms, problems or issues.

Runtime Analysis Analyze

Analyze the runtime behavior of the system, e.g. with respect to time and resource consumption or creation.

Runtime Artifact Analysis stub Analyze

Artifacts that were created by a running system are a gold mine. They allow you to get a deeper understanding of the inner workings of a software system. Use log management, aggregators and monitoring tools to gather log files. Then analyze usage patterns, stack traces or errors to see what the system is really doing.

Sample for Improvement stub Improve

Provide concrete code example for typical improvement situations, so that developers can improve existing code easily.

Schedule Work stub Improve

Schedule refactoring or improvement work, so that all (business and technical) stakeholders know about them.

Separate Cause from Effect Cross-cutting

Explicitly differentiate between symptom (effect) and cause: identify root causes of symptoms, problems or issues.

Slide or Write Cross-cutting

Consider format and structure of the review report early.

Social Debt Analyze

Evaluate and track the welfare and health of a software development and operation organization or community such that additional project cost can be avoided or somehow managed.

Software Archeology Analyze

Understand software by examining existing source code.

Stakeholder Analysis Analyze

Ensure that all concerned parties are addressed.

Stakeholder Interview Analyze

Learn from the people who know or care about the system and everything around it.

Stakeholder-Specific Communication stub Cross-cutting

Communicate with stakeholders by actively applying their specific or favored terminology and/or communication channels.

Static Code Analysis Analyze

Analyse source code to identify building blocks and their dependencies, determine complexity, coupling, cohesion and other structural properties.

Strangler Approach Improve

Divide a legacy system into different functional domains and replace those step by step.

Structural Analysis stub Analyze

Analyze the static structures (e.g. building block structure) of the system, e.g. package or module dependencies, runtime- and/or deployment dependencies. See the more specific Static Code Analysis, Context Analysis and Data Analysis.

Systematic Decisions stub Cross-cutting

Systematically prepare and take decisions by finding appropriate options, check assumptions, overcome emotion and prepare to be wrong. See Decisive (by C+D Heath).

Take What They Mean, Not What They Say Analyze

Find out the real meaning/intention of stakeholders

Toggle Feature stub Improve

Simultaneously support evolved, competing or conflicting features at runtime by toggling feature flags.

Traceability Cross-cutting

When discussing problems, some stakeholders will question or doubt your findings (see pattern Expect Denial). Keeping thorough references to the origins or original sources of major findings keep eventual critics in check.

Untangle Code stub Improve

Remove unnecessary complications in code, e.g. nested structures, dependencies, dead-code, duplicate-code etc. See Remove Nested Control Structures. Special case of Refactoring.

Use Case Cluster stub Analyze

Understand system functionality by grouping functionality into clusters to reduce complexity.

Use Invariants to Kill Zombies Improve

Provide a safe approach in situations where it seems to dangerous to delete code or whole modules from a huge system because Static Code Analysis can’t recognize whether the code is still in use or not.

User Analysis Analyze

Get an overview of user categories or groups, their goals, requirements and expectations. Find out about issues users have with the system.

View-Based Understanding Analyze

Understand the inner workings and internal (code) structure of of the systems. Document (and communicate) this via architectural views, especially the building-block view.

Widen Your Options stub Cross-cutting

Before taking decisions it’s often a good idea to widen your decision space, look for additional options. Sometimes it’s not only “yes-or-no” decisions, but a spectrum of additional options are available - at least if you allow your brain to deviate from conventional path or your own preliminary conclusions.

Analyze

Evaluate

Improve

Cross-cutting

All patterns, A–Z