The principle of symmetric change


News: The principle of symmetric change

  1. The principle of symmetric change (1 messages)

    Gojko Adzic wrote a post about "the principle of symmetric change," which he says is the most important lesson he learned from a book "Specification by Example." It means that a small business model change should mean a small code change.

    He organizes a way to help this happen in four bullet points:

    • each specification should be focused on a single concept of the business domain model (which might be a business rule, step in a flow, or something higher such as the overall definition of a business process)
    • the concepts used in key examples in a specification are closely aligned with the business domain model and reflected in underlying software domain model. this includes naming (concepts are described in the business domain language) but also the relationships between them.
    • the (automated) validation procedure is clearly separated from the specification of key examples
    • the specifications are organised into a living documentation system according to the conceptual relationships that exist in the business domain model

    "By thinking about aligning the language and abstraction concepts in the specifications with the business domain model, we force ourselves to describe what the software should do, not how it does it. This separates the specification (what) from the validation procedure (how can we check it in software). The validation procedure can then be automated using a tool."


    Ensuring that the specifications are aligned with the business model and in the business language, organised according to the relationships the underlying concepts have in the business model solves all the reasons behind the “Tests unusable as live documentation” family of problems, and ensuring that the previous documents are still aligned with the new model resolves most of the issues we described as “Test code not maintained with love”.

  2. I heard of this many years ago described as the 'principle of least astonishment' i.e. things that appear simple to change should be and vice versa - although generally I don't mind if things turn out to be simpler to code than they appear.