Reference:
Looking at the current DevIQ Values page, it’s intentionally focused on the five XP values: Communication, Courage, Feedback, Respect, and Simplicity. Those are excellent foundational values, but if your goal is to create a broader taxonomy that underpins software engineering, architecture, principles, laws, and antipatterns, I’d expand it significantly.
I would organize them into several categories.
Architectural Values
Modularity
The ability to reason about, build, test, deploy, and evolve parts independently.
Supports:
- Separation of Concerns
- High Cohesion
- Low Coupling
- Modular Monoliths
- Microservices (when appropriate)
- Information Hiding
Violations lead to:
- Big Ball of Mud
- Distributed Monolith
- Shotgun Surgery
⸻
Adaptability
Software should be easier to change than to rewrite.
Supports:
- Open/Closed Principle
- Evolutionary Architecture
- Refactoring
- YAGNI
Violations lead to:
- Brittle Systems
- Architecture Astronautics
- Speculative Generality
⸻
Maintainability
Future developers matter as much as current developers.
Supports:
- Clean Code
- Self-documenting Code
- Consistent Patterns
- Refactoring
Violations lead to:
- Technical Debt
- Cargo Cult Programming
- Code Rot
This is arguably one of the most important values in professional software development.
⸻
Observability
A system should explain itself when it fails.
Supports:
- Logging
- Metrics
- Tracing
- Health Checks
- Telemetry
Violations lead to:
- “Works on my machine”
- Production debugging by guesswork
⸻
Engineering Values
Clarity
Code is written for humans first and machines second.
Supports:
- Good Naming
- Ubiquitous Language
- Explicitness
- Self-documenting Design
Violations lead to:
- Clever Code
- Obscured Intent
- Magic Behavior
Many code smells ultimately stem from violating clarity.
⸻
Correctness
Software should do what it claims.
Supports:
- Testing
- Design by Contract
- Validation
- Strong Types
- Value Objects
Violations lead to:
- Primitive Obsession
- Hidden Assumptions
- Invalid State
⸻
Reliability
Systems should behave predictably.
Supports:
- Defensive Design
- Fault Tolerance
- Idempotency
- Retries
Violations lead to:
- Cascading Failures
- Fragile Systems
- Race Conditions
⸻
Consistency
The same problem should have similar solutions.
Supports:
- Coding Standards
- Architectural Standards
- Shared Conventions
Violations lead to:
- Oddball Solutions
- Surprise Costs
- Increased Cognitive Load
⸻
Human-Centered Values
Empathy
Software exists to serve users and developers.
Supports:
- UX Design
- Developer Experience
- Accessibility
- Domain-Driven Design
Violations lead to:
- Leaky Abstractions
- Hostile APIs
- User Frustration
⸻
Trust
Stakeholders should be able to trust the system and the team.
Supports:
- Transparency
- Security
- Privacy
- Ethical Software Design
Violations lead to:
- Hidden Side Effects
- Security Theater
- Dark Patterns
Trust has become increasingly important in AI-enabled systems. Research on value-sensitive software design frequently identifies privacy, fairness, security, autonomy, and trust as core values.
⸻
Economic Values
Value Delivery
Software exists to create value, not merely features.
Supports:
- Lean Thinking
- MVPs
- Outcome-Based Development
- Product Thinking
Violations lead to:
- Feature Factories
- Gold Plating
- Architecture for Architecture’s Sake
⸻
Pragmatism
The simplest solution that works is often the best solution.
Supports:
- KISS
- YAGNI
- Incremental Design
Violations lead to:
- Overengineering
- Architecture Astronautics
- Premature Optimization
⸻
Values that Underpin Laws
One interesting approach would be to explicitly connect values to laws.
Law Underlying Value
Conway’s Law Alignment
Brooks’s Law Communication
Gall’s Law Incremental Evolution
Postel’s Law Robustness
Law of Demeter Encapsulation
Parkinson’s Law Efficiency
Goodhart’s Law Value Delivery
Hyrum’s Law Predictability
Lehman’s Laws Adaptability
This creates a nice hierarchy:
Values → Principles → Practices → Patterns → Laws → Antipatterns
For example:
Value: Modularity
Principle:
Separation of Concerns
Practice:
Encapsulation
Pattern:
Module
Law:
Law of Demeter
Antipattern:
Big Ball of Mud
If I Could Only Add Five
If DevIQ were expanded beyond XP and I had to pick only five additional values, they would be:
- Modularity – enables scale and evolution.
- Adaptability – software is expected to change.
- Clarity – complexity is the enemy.
- Maintainability – future developers matter.
- Value Delivery – software exists to solve problems, not create artifacts.
Those five form the foundation for a surprisingly large percentage of modern software engineering principles, architectural patterns, and laws. In fact, most code smells and architectural antipatterns can be described as violations of one or more of those values.
Reference:
Looking at the current DevIQ Values page, it’s intentionally focused on the five XP values: Communication, Courage, Feedback, Respect, and Simplicity. Those are excellent foundational values, but if your goal is to create a broader taxonomy that underpins software engineering, architecture, principles, laws, and antipatterns, I’d expand it significantly.
I would organize them into several categories.
Architectural Values
Modularity
The ability to reason about, build, test, deploy, and evolve parts independently.
Supports:
Violations lead to:
⸻
Adaptability
Software should be easier to change than to rewrite.
Supports:
Violations lead to:
⸻
Maintainability
Future developers matter as much as current developers.
Supports:
Violations lead to:
This is arguably one of the most important values in professional software development.
⸻
Observability
A system should explain itself when it fails.
Supports:
Violations lead to:
⸻
Engineering Values
Clarity
Code is written for humans first and machines second.
Supports:
Violations lead to:
Many code smells ultimately stem from violating clarity.
⸻
Correctness
Software should do what it claims.
Supports:
Violations lead to:
⸻
Reliability
Systems should behave predictably.
Supports:
Violations lead to:
⸻
Consistency
The same problem should have similar solutions.
Supports:
Violations lead to:
⸻
Human-Centered Values
Empathy
Software exists to serve users and developers.
Supports:
Violations lead to:
⸻
Trust
Stakeholders should be able to trust the system and the team.
Supports:
Violations lead to:
Trust has become increasingly important in AI-enabled systems. Research on value-sensitive software design frequently identifies privacy, fairness, security, autonomy, and trust as core values.
⸻
Economic Values
Value Delivery
Software exists to create value, not merely features.
Supports:
Violations lead to:
⸻
Pragmatism
The simplest solution that works is often the best solution.
Supports:
Violations lead to:
⸻
Values that Underpin Laws
One interesting approach would be to explicitly connect values to laws.
Law Underlying Value
Conway’s Law Alignment
Brooks’s Law Communication
Gall’s Law Incremental Evolution
Postel’s Law Robustness
Law of Demeter Encapsulation
Parkinson’s Law Efficiency
Goodhart’s Law Value Delivery
Hyrum’s Law Predictability
Lehman’s Laws Adaptability
This creates a nice hierarchy:
Values → Principles → Practices → Patterns → Laws → Antipatterns
For example:
Value: Modularity
Principle:
Separation of Concerns
Practice:
Encapsulation
Pattern:
Module
Law:
Law of Demeter
Antipattern:
Big Ball of Mud
If I Could Only Add Five
If DevIQ were expanded beyond XP and I had to pick only five additional values, they would be:
Those five form the foundation for a surprisingly large percentage of modern software engineering principles, architectural patterns, and laws. In fact, most code smells and architectural antipatterns can be described as violations of one or more of those values.