Principles, Parameters, and Practices
From Mp
When approaching Methodology Design from the perspective of "first principles," it's important to understand what motivations and basic concepts to apply. There are three basic "inputs" into designing a methodology: principles, parameters, and practices.
Principles
Principles are a fundamental part of defining a Software Development Methodology because they represent what's important to the individual, the team, group, or organization. It represents the basic culture and needs, as well as values. Principles represent the primary motivation behind the design. If the practices being implemented do not logically flow back to a principle, then it's questionable whether the practice is necessary or desired. On the other hand, a strong desire for a particular practice may imply a particular principle.
What is a principle, really? What does it look like? And why not just select all good principles in the first place? A principle is a fundamental motivation. Different organizations, teams, or individuals may have different principles that guide and help them. In most cases, there are common principles that are applicable across most development organizations, such as some form of quality, customer satisfaction, etc. However, merely using a principle of "quality" and "customer satisfaction" may be too vague for use, especially when those principles may contradict each other (for example, a customer may be more satisfied with less quality and a better, shorter, schedule). For example, a more specific version may be something like: "We value providing our customers with confidence through producing quality software that is appropriate for our customers' needs."
And why not just select numerous "good" principles? Because a principle acts as the main driving force in defining a methodology, it's expected that the practices selected will support and ensure that the principle is achieved. Therefore, unless you're willing to sign up for the logical practices that would support the principle, then the principle may not be appropriate as a motivating factor. Also, as more and more principles are added, they tend to conflict with each other in some way (such as quality and customer satisfaction).
Parameters
Parameters are typically external pressures, forces, or environmental constraints that affect the way software can be built. For example, projects built with a firm, fixed budget may be built differently than projects with time and materials budgeting constraints. Methodologies that wish to be CMMI certified have that as a constraint (meaning, the set of practices must support the constraints that CMMI dictates). Parameters may also come in the form of an overall corporate culture. Software built in-house may be built differently than software built for an external customer. All of these parameters may affect which practices are selected and how they are implemented.
Parameters are secondary motivators, but are the primary inputs into practice selection. Where principles primarily imply practices, parameters constrain and modify implementations of practices. Parameters may also imply practices, but they do so in a secondary manner.
Practices
Practices represent what is actually done within the methodology. Practices are "wrapped" around The Core Process. They may be selected from a set of many existing practices, with changes to their implementations as needed, or, they may be invented to support some principle or parameter.
For example, peer reviews (such as code reviews) are an excellent way to ensure some form of quality. However, they may be implemented as simple spot checks by technical leads or architects, or they may be informal reviews by a couple of team members. They may even be implemented using a formal review process. Pair programming can also be used as a way to implement them. Which to choose depends upon what's appropriate, based upon the principles and parameters being used to design the methodology.
