Whilst principles both provide guidance and rationale for behaviors, they are semi-useful on their own. Principle-Driven Engineering (PDE) builds on this by giving you a deeper understanding of how to work with multiple principles in a way that will actually get used, rather than becoming something that is a burden.
Principle-Driven Engineering uses Principles to rapidly share understanding and behavior in teams and technology organizations, making them more productive.
It aligns behaviors by providing guidance and improves capability by transferring knowledge, getting better results from software engineering organizations.
Why use PDE
- Tames codebases
- Creates emergent behaviors in the organization
- It reduces conflict
- Shared learning
- Enables higher levels of complexity
- Principle framework
The interaction of principles creates more complex behavior. When you use more than one principle, behaviour can overlap and conflict. We'll discuss how to work with principles using things such as priority, exceptions, discovering other principles or refining existing ones.
Principle framework - The organization of principles depending on how they are being used
Principle framework is about collecting principles into a framework of explicit behaviors, to give users the mental tools they need to act for interacting with a codebase that is both explicit and contextual. It speeds up development rapidly as users can orientate themselves more rapidly on a system. It might sound complicated, but you will be familiar with this concept, but you may have never thought about it this way before.
If you use a codebase, library, or framework for the first time you will be using someone else's design. Most times the principles behind the frameworks are hidden, and it's your job to discover them as you learn to use the framework by repeating their patterns over and over.
Naming - The grouping of principle frameworks into uniquely named structure
The beginning of wisdom is to call things by their right names. – Confucius
Naming in PDE involves assigning unique names to things and grouping them with a designated set of principles. The purpose is to share mental models between teams members unencumbered from prior learnings and habits. It is using names that have no existing meaning to you or your team, so team members aren't primed with prior learnings.