This is part of a discussion about among others GivingNewDefinitionsToOldWords moved from patterns-discussion to here. Wandering from PurposeOfPatterns to PrinciplesObjectivesAndGoals to DoWeHaveToStickToDictionaries.
(I've reformatted this but it could do with a refactoring. Please check my reformatting hasn't invalidated any of the points being raised.)
Design principles can be understood as sub-objectives which are supposed to influence higher objectives like software quality or the like. The need for sub-objectives is obvious because of the complexity of an objective like quality. The intent of all design principles is to generate the given objectives.
Let's switch to patterns: the forces can be subdivided into constraints and objectives. Constraints are given properties which have to be dealt with. Take for example a certain degree of centralization in an organisation which has developed over time and shouldn't be changed. The objectives can be design principles but others are possible, too. For example minimizing run time isn't a design principle but could be a force in a time critical system. The non-constructiveness of objectives and constraints causes the problem which can be solved by the pattern solution in at least one possible way (often not all forces can be resolved in an optimal manner because there are conflicts between them).
IMO design principles understood as objectives are part of the forces in design patterns. -- M.Schlitt
In psychology and anthropology, principles and values create the goals that drive normative behavior, but they are not themselves the goals or values. For example, a company might ascribe to the economic theory of value so it retains investors (as opposed to, for example, optimizing revenue or profitability). That's a value or principle. The goal is to survive through the primary objective of maintaining or increasing stock value. The objectives that support that goal include good marketing campaigns, delivering quality products, and offering good follow-up service. There are patterns that support these objectives.
So I don't think of design principles as objectives. For example, coupling and cohesion are principles but not objectives. An objective is something that can be accomplished at a well-defined point in time. Goals are desiderata that define a direction without necessarily defining a measurable end. Values and principles point to the direction toward goals, without specifying the goals or the means to achieve them. -- JimCoplien
There are different meanings affiliated with the terms goal, objective and principle, I think. In my work (concerned with business processes and application systems to support them) I use the terms as follows:
Goals describe the things to be achieved by a task. They determine the type of output or service ("What is the output of the task?").
For example the goal of a marketing task is to do marketing campaigns, the goal of a production task is to produce goods or services of a certain kind. Objectives are dependent on goals. They aim at the degree of freedom which is given by a certain goal if any ("How is the output to be achieved?"). Take for example cost limits of marketing campaigns or quality standards for produced goods or services.
They both don't specify a way to achieve the goals and objectives but describe the desired output and give constraints as well. Hence they can be used to describe a problem.
Principles are more difficult to describe definitely. There is a wide range of usage for this term. Some principles are more like objectives, others are more closely related to the way to achieve given goals and objectives ( "cohesion an coupling" is supposed to support objectives like extensibility or reusability of software systems). It can be stated that principles are non-constructive but describe properties of the solution. in this sense I agree with you when saying that
The following diagram is helpful to describe what you are trying to say. The diagram is best in a non proportional font
Objectives ----> Goals --> Milestones ^ ^ | | Strategy ------> TacticsWhich is to say that Objectives can be decomposed into a sequece of Goals, which can be decomposed into a sequence of Milestones.
Strategy belongs in the Objectives folder, Tactics belong in the Goals folder. A Strategy can be decomposed into a sequence of Tactics.
In this abstraction, items of class Fuzzy are commonplace <s>. -- StevenBlack
I'm becoming more confused. couldn't it be the other way around? Strategy and goals, Tactics and objectives.
Our goals, personal or our organization's, arise from our vision of the future, broader policies or principles. We have a set of longer term goals and a strategy to achieve them. We set short term objectives (and some form of measure, qual or quan) and tactics to achieve the strategy (or strategic plan). I think objectives imply some sort of time-scale (with deadlines and milestones)for its achievements and a level of service, required capabilities...
Strategy and goals are closer to the values and pursue of mission. -- MartineDevos
Different systems use the terms in different ways. See LifeVectors for a slightly different staging and labeling of the tiers. -- GarryHamilton
Continued under DoWeHaveToStickToDictionaries at a more abtract level.