Principles Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Describing Principles ======

All [[glossary:principles]] in this wiki are [[glossary:principle description|described]] using a certain description template. This makes the wiki a [[glossary:principle catalog]].


===== Variants and Alternative Names =====

Each principle may have several alternative names. This may be because the same principle has been described several times independently. A principle may also evolve over time, change its name, change its meaning, may be applied to other contexts, etc. So there may be several names referring basically to the same principle. This also means that the alternative names may roughly correspond to certain views on the principle. The views may differ slightly resulting in certain variations of the principle. Alternative names are listed in this section and, if necessary, explained. The views may differ slightly resulting in certain variations of the principle.

Alternative names are listed in this section and, if necessary, explained. Variations are also explained and, depending on the difference, may additionally be described on a separate wiki page.


===== Context =====

Principles apply in certain [[contexts:]]. A context is a basic category for principles like OOD, web development, framework development, user interface design, etc. It describes during which task the principle can be considered. A principle has at least one context but also may have several contexts.


===== Principle Statement =====

The principle statement is basically a concise explanation in one or two sentences. This may be the original wording or a new one. The main purpose is to give a memorable "definition" of the principle.


===== Description =====

As one or two sentences are never enough to explain a principle in detail, there is a separate section describing what the principle means and how it is applied.


===== Rationale =====

Principles normally are not hard rules but rather heuristics or rules of thumb. So there is no formal proof showing that the principle is correct in each and every situation. Nevertheless there needs to be a reason for the principle, meaning some rationale explaining why it is valid. In order to assess whether the principle is applicable to a certain problem, the rationale can be used. If the reasons given in this section apply to the given problem, the principle can be applied.


===== Strategies ======

The main idea behind principles is to assess solutions and not to construct solutions. Nevertheless applying principles may lead to the conclusion that a solution is not as good as it could be. This section lists strategies that can be used to transform a given solution in a way that the result better adheres to the principle. So the principle language provides guidance beyond the pure assessment of design solutions. A generative approach for constructing solutions is nevertheless necessary.


===== Caveats =====

This section lists warnings on how //not// to use this principle. Disadvantages are partly treated below in the section "contrary principles". Nevertheless there are sometimes helpful remarks on pitfalls and wrong usages that cannot be described using contrary principles or that are otherwise noteworthy. This section discusses these issues.


===== Origin =====

This section describes where the principle comes from, where it has been prominently described, etc.


===== Evidence =====

Apart from the rationale there may be different evidence that the principle holds:

  * [[wiki:Proposed]]: If the principle is neither //examined//, not //accepted// it is marked //proposed//. This is the default.
  * [[wiki:Examined]]: A principle is marked //examined// if and only if it has been subject to scientific research showing evidence beyond constructed examples. Note that this state is called "examined' and not "proven" as the examination may have limitations and the principle may still be //questioned//. If the scientific examination supports the principle, it may be considered state of the art.
  * [[wiki:Accepted]]:  A principle is marked //accepted// if and only if it is widely used in practice. Acceptance is assumed if a publication (a book, etc.) well-known among practitioners describes it. So an accepted principle can be regarded state of the practice. 
  * A principle may be both //examined// and //accepted//.
  * [[wiki:Questioned]]: Independent of whether a principle is //proposed//, //examined//, //accepted// or //examined// and //accepted//, a principle may also be //questioned//. This is the case when someone has expressed reasonable arguments against it. It doesn't matter who questioned the principle but there has to be some understandable reason. Furthermore the principle itself needs to be questioned. It is not sufficient that keeping the rule may inevitably also have some negative effects expressed by another principle. This is normal due to the nature of the principle definition used here. A principle is //questioned// if there is doubt concerning the positive effect it claims to have.


===== Relations to Other Principles =====

There are certain relationships among principles. This section lists and explains them so the consideration of one principle inevitably leads to other principles that can be considered. An important aspect of this is that the pure purpose of this list of relationships is to give a clear navigation path to the principles that should be considered next. These relationships are fuzzy and sometimes not valid in every respect. But this is not a problem since their purpose is to be practically useful. A purely "academic" analysis of the principles which ignores their practical usage is not intended.

==== Generalizations ====

A generalization of a principle is another principle that can be applied in a broader context or one that is less demanding. Generalizations may be considered in addition or instead of the principle. If a principle does not fit well to the problem, a generalization of it may fit better. It may also add further reasons and a broader view for the assessment of possible solutions.

The principle is always a specialization of its generalizations. There may also be several generalizations, for example when a principle is a consequence of two others.

==== Specializations ====

A specialization is a more concrete principle that either applies in a narrower context, makes more prescriptions, or is some kind of corollary. Specializations may be considered in addition or instead of the principle. If a principle does not fit well to the problem, a specialization of it may fit better. It may be easier to apply and more tailored to specific kinds of problems.

The principle is always a generalization of its specializations and naturally there may be several specializations.

==== Contrary Principles ====

Following the principle may have a negative impact on aspects addressed by other principles. These contrary principles are listed here and the consequence is explained. Like there is no guarantee that the principle itself is valid in every case, there is also no guarantee that there is the negative effect concerning the other principles. There is just a high probability that there is this effect. Therefore these principles should also be considered if this one is applied.

As the relationships are purely for navigational purposes, the "is-contrary-to" relationship is not necessarily symmetric.

==== Complementary Principles ====

A principle is always a reduction of the given design problem to a very specific aspect or effect. Other principles have to be considered too in order to have a full picture of the design problem. Sometimes when one principle is considered, another one is very likely to be relevant too despite not being contrary. This is then a complementary principle. As for the other relations this is just a tendency and a purely navigational relationship. In practice a complementary principle may also be contrary or not applicable.

Similar to "is-contrary-to", the "is-complementary-to" relationship is not necessarily symmetric.

==== Principle Collections ====

This section lists all [[glossary:principle collections]] (including [[glossary:principle languages]]) that include the principle.

===== Examples =====

One or more self-contained examples explains how the principle distinguishes "good" and "bad"' solutions with respect to the aspect the principle is about or exemplifies certain relationships, strategies, caveats, etc.


===== Description Status =====

As the wiki page evolves, it gets better and better. This section roughly states how complete it already is:

  * [[wiki:Stub]]: Typically a wiki page starts as a //stub// and is then enhanced over time. A stub only contains the most necessary information. 
  * [[wiki:Incomplete]]: If the principle description is not yet //complete// but already contains significantly more than a stub, it is called //incomplete//. See [[wiki:incomplete|wiki:incomplete]] for the precise requirements.
  * [[wiki:Complete]]: A wiki page with no obviously missing information is called //complete//. It may still be possible to enhance and improve it but there are no real gaps anymore. See [[wiki:complete|wiki:complete]] for the precise requirements.


===== Further Reading =====

Apart from the original source which may be already mentioned in the origin section there may be other articles, discussions and wikis discussing the principle. If they are worth looking into, they are listed here.