Q42 Exposed: Is ISO25010 Finally Obsolete?
The arc42 team's alternative quality model challenges decades of software quality dogma with 8 pragmatic attributes that might actually get used.
The ISO25010 standard has been the software quality bible for over a decade, but most developers couldn’t tell you what’s actually in it. That’s precisely the problem Q42 aims to solve, not by adding more complexity, but by stripping quality down to what actually matters in modern software development.
The ISO25010 Conundrum: Too Much Theory, Not Enough Action
Let’s be honest: when was the last time you referenced ISO25010 during a design review? The standard defines 31 quality characteristics organized into 8 major categories, but its academic approach leaves practitioners scratching their heads about practical implementation. The official documentation reads more like a taxonomy textbook than actionable guidance for shipping better software.
This frustration isn’t just anecdotal. The creators of Q42 explicitly state that current quality standards like ISO25010 “lack practical guidance and pragmatism” ↗. They’re calling out what many architects have felt for years, that we need quality models that teams will actually use, not just ones that look comprehensive on paper.
Even the recent 2023 update to ISO25010 did little to bridge this implementation gap. While it refined some definitions and added minor improvements, it maintained the same fundamentally abstract approach that makes quality feel like someone else’s problem.
Q42’s Radical Simplicity: Eight Properties to Rule Them All
Q42 (pronounced “Kju-Fortytwo”) takes a drastically different approach. Instead of trying to categorize every conceivable quality aspect, it focuses on eight top-level properties that cover “most, if not all, required, desirable or expected” qualities. Here’s the condensed framework:
| Property | Coverage | Practical Focus |
|---|---|---|
| #reliable (97) | Perform specified functions without interruptions | Uptime, fault tolerance, stability |
| #flexible (50) | Adapt to changing requirements | Modifiability, extensibility, versatility |
| #efficient (71) | Optimal resource usage | Performance, throughput, capacity |
| #usable (103) | User experience and effectiveness | UX, accessibility, learnability |
| #safe (28) | Avoid dangerous states | Safety-critical systems, warnings |
| #secure (36) | Protect against threats | Security, privacy, access control |
| #suitable (52) | Meet stakeholder needs | Fitness for purpose, completeness |
| #operable (55) | Easy to deploy and monitor | DevOps, observability, management |
The parenthetical numbers reveal how the model actually works in practice: each property covers multiple specific quality attributes. For example, the #operable tag encompasses 55 distinct qualities and requirements related to deployment, monitoring, and operational management. This interlinked structure means you’re not starting from scratch, you’re leveraging a curated collection of proven quality considerations.
Why Q42 Hits Different for Modern Systems
What makes Q42 particularly compelling for contemporary software development isn’t just its simplicity, it’s how the properties align with today’s architectural realities.
Take #operable, for instance. This single property bundles observability, deployability, monitorability, and controllability, all concerns that have become first-class citizens in the cloud-native era. ISO25010 treats these as secondary characteristics scattered across multiple categories, but Q42 acknowledges that operational quality determines whether your system survives contact with production.
Similarly, #flexible embraces the reality that most software lives longer than its original requirements. While ISO25010 has “modifiability” buried under maintainability, Q42 makes adaptability a core property that spans everything from configuration changes to complete architectural pivots.
The model’s creators explicitly designed it to “start with stakeholders’ expectations and requirements”, flipping the traditional quality discussion from “what qualities should we consider?” to “what properties matter to our specific context?” This stakeholder-first approach eliminates much of the theoretical overhead that plagues traditional quality models.
From Abstract to Actionable: The Q42 Implementation Mindset
The real magic of Q42 isn’t in the high-level properties but in how they’re operationalized. The framework provides 114 concrete examples of quality requirements ↗ and links them to specific implementation patterns and standards.
Consider #secure, instead of vague statements about “information security”, you get requirements like:
- “The system shall prevent SQL injection attacks”
- “All data in transit must be encrypted using TLS 1.2 or higher”
- “User sessions shall timeout after 30 minutes of inactivity”
These aren’t just abstract qualities, they’re testable, implementable requirements that development teams can actually work with. The model even includes cross-references to relevant standards and patterns for each requirement, bridging the gap between quality intent and implementation reality.
The Developer Experience Revolution
Perhaps Q42’s most radical departure from tradition is its implicit focus on developer experience. Properties like #operable and #flexible directly impact how developers interact with systems throughout their lifecycle. While ISO25010 treats development-time qualities as separate from runtime qualities, Q42 acknowledges they’re deeply interconnected.
Modern development practices like DevOps, CI/CD, and infrastructure-as-code have blurred the lines between development and operations. A system that’s difficult to deploy (#operable) inevitably suffers in development velocity (#flexible). Teams wrestling with cumbersome deployment processes spend less time building features and more time fighting infrastructure.
This holistic view resonates with development teams who’ve long recognized that quality isn’t just about what users experience, it’s also about what developers endure. As one architect noted in discussions about the model, this approach helps “quantify quality in design” in ways that actually influence architectural decisions.
Pragmatism Over Perfection
Q42 isn’t trying to replace ISO25010 in standards committees, it’s trying to replace it in design meetings, architecture reviews, and requirement documents. Its value proposition isn’t comprehensiveness but usability.
For teams building modern distributed systems, cloud-native applications, or microservices architectures, Q42’s property-based approach aligns better with contemporary concerns like observability, resilience, and developer productivity. The framework’s emphasis on concrete requirements and practical implementation makes quality discussions more productive and less theoretical.
The model’s interactive quality graph, which allows you to explore relationships between specific qualities, requirements, and standards, demonstrates this practical orientation. You’re not just reading about quality, you’re exploring how it manifests in real systems.
As the software industry continues its shift toward more dynamic, distributed, and rapidly evolving systems, our quality models need to evolve accordingly. Q42 represents a serious attempt to create a quality framework that works with how modern teams actually build software, not how standards bodies wish they would.
The question isn’t whether ISO25010 is “wrong”, it’s whether there’s a better way to think about quality that leads to better software. Q42 makes a compelling case that sometimes, less really is more.
