Constructing Principle Languages

There are tens and maybe hundreds of principles. In order to form a concise vocabulary of principles for communicating about software design a manageable subset is needed. Such a subset forming a principle language can be taught and learned more easily. But constructing such a principle language comprises some complicated tasks and considerations. The following aspects have to be kept in mind when constructing a principle language:

• Coverage: A principle language should cover most of the arising design problems in the context it is built for. This means that the principle language has be be large enough to have this kind of coverage but otherwise as small as possible so it is still learnable.
• Granularity: Typically specialized principles are more helpful and easier to apply than general ones. But they are applicable in less situations.
• Navigation: The relationships between the principles cannot be constructed by purely looking at the principles. The relationships should not represent some academic concept but help traversing the principle language. Therefore finding the right relationships works the following way:
  • For each principle A
    • For each other principle B
      • Envision which kinds of design decisions are made when considering principle A
      • If in these situations one would want to consider also B then insert a relationship from A to B
• Relationship Types: There are different types of relationships between principles. Generalization/specialization can be used to find more appropriate principles replacing currently considered ones, contrary principles point out important drawbacks, and complementary principles show further aspects which may be worth considering. But these relationship types are not as clear as it seams. Principles which are contrary in one situation may be complementary in another one, etc. So for specifying the “correct”, i.e. most helpful relationship type, it is necessary to again envision the typical design situations for the principle and find out which relationship is helpful in the most situations.
• Shortcut Relationships: Traversing a principle language is transitive to some extend. Suppose there are the principles A, B and C. Considering A may lead to B and considering B may lead to C. In such a case there is the question whether or not to create a “shortcut-relationship” directly going from A to C. The difference is that in the first case C is only considered when B is considered. In the second case the shortcut creates a direct navigation path from A to C. So C can be considered without having B. Here is also the question how a developer would want to navigate the principle language. It depends on the possible design decisions and not merely on the principles.