What good software looks like at REA
Alison Rosewarne · article · 2018-06-12 Reader 🖥️
Changeability & OptionalityCode QualityModularity & CouplingPlatform EngineeringSociotechnical ArchitectureSoftware Design Fundamentals
What makes software 'good' at REA is not a single abstract ideal but three concrete, criteria-based lenses — dev (changeability), ops (operability), and arch (bounded responsibility) — that the teams who own each system rate themselves against on a recurring basis, so architectural quality becomes an organizationally-supported habit rather than a one-time design decision.
practical · mixed — Primarily expository — it documents an existing internal practice — but structured argumentatively: it justifies why three lenses (not one, not many), why quality/security are folded rather than separate, and why the custodianship/devops/microservices trio matters. Ultimately practical: it argues for a way of assessing and driving change in software, not just for understanding it.
Structure
| Part | Role |
|---|---|
| Introduction: framing the problem of heterogeneous software needing a shared quality vocabulary | context |
| The categories overview: dev/ops/arch lenses, three-tier rating scale, and the decision to fold quality/security in rather than call them out separately | core framework definition |
| 'About REA': company history (Perl to polyglot, garage to hundreds of engineers, ad-hoc servers to cloud) and the three most consequential recent changes (micro-services, devops, application custodianship) | causal context / evidence for why the framework takes this shape |
| Dev / Ops / Arch sections: for each lens, a defining question plus specific bulleted criteria at three tiers of expectation | operational detail — the actual assessable content |
| Conclusion: framing 'good software' debate as an ongoing craft discipline, plus the periodic review process and its organizational payoff | conclusion / call to ongoing practice |
Key terms
- Dev (lens)
The changeability quality of a system: can a developer set up the codebase, understand it, and confidently make changes to it. - Ops (lens)
The operability/reliability quality of a system: can it be deployed, understood along with its dependencies, recovered from disaster, and verified against SLAs. - Arch (lens)
Whether a system encapsulates a single responsibility behind a clearly defined interface within understood domain boundaries — explicitly called out as cross-cutting (unlike quality/security, which are folded into the other two lenses) because architecture was judged to need its own forum for debate. - Application custodian
The team (within a cross-functional 'tribe') that owns a system's architecture, technical decisions and quality; must approve any major change proposed by another team, and performs the quarterly health rating. - Health rating
The quarterly output of a custodian's review of their system against the dev/ops/arch criteria; tracked centrally in a web UI and feeds into planning and other activities. - Internally open source
All REA systems are visible and editable via pull request by any team internally, though the custodian retains sole approval authority over major changes. - Cattle not pets
Used as a specific 'meets expectations' criterion under the Ops lens: infrastructure should be disposable/replaceable and managed via automation/infra-as-code, not hand-nursed individual servers.
Propositions
- explicitGood software cannot be captured by a single universal quality; REA uses three distinct lenses — dev, ops, arch — because different stakeholders need different guarantees (changeability, operability, well-bounded responsibility) from a system.conf: highextendsAgents don't know what good looks like. And that's exactly the problem. · p3 — REA's dev/ops/arch rubric is a concrete, human-executed instance of the 'capability verification' (operational quality beyond functional correctness) that the AI-era piece says remains hard for agents and many human developers alike — REA shows what an organization actually built to do it, at pre-AI human-review scale.
- explicitQuality and security are best treated as cross-cutting concerns folded into the three lenses' criteria rather than standalone categories, because isolating them as separate lenses would fragment accountability for properties that are inherently pervasive.conf: high
- explicitA low barrier to making changes is valuable only if it doesn't compromise quality — changeability and quality are companions to be jointly optimized, not traded off against each other.conf: high
- explicitRating software against explicit, tiered criteria (meets / partially meets / falls significantly short) rather than leaving 'good' as tacit team consensus makes architectural expectations discussable, comparable across teams and technologies, and actionable.conf: high
- explicitMicro-service architecture succeeded at REA because it consolidated a single responsibility into small, independently verifiable and deployable components, replacing monolithic systems whose blurred domain boundaries made them testable only in lockstep with other 'monolith friends.'conf: high
- explicitEmbracing a devops culture — giving the team that builds a system full lifecycle ownership of deploying, monitoring and supporting it — was a necessary enabler of the shift to micro-services, not an independent initiative.conf: highsupportsThe Organization Is the Bottleneck · p5 — REA's detailed account of devops culture and application custodianship as prerequisites for its micro-service architecture is a concrete corroborating case for the claim that microservices succeed or fail on organizational/cultural setup rather than technology choice.
- explicitArchitectural quality requires a specific accountable owner (the 'application custodian') with real authority over architecture, technical decisions and quality; without an active custodian, criteria go unenforced.conf: high
- explicitSystems being internally open (any team may submit a pull request) does not weaken architectural governance, because approval authority for major changes stays with the custodian regardless of who authored the change.conf: high
- explicitCentrally-provided platform resources (CI, wikis, artifact repositories, vulnerability scanning, monitoring, delivery engineering) are part of how teams actually meet the criteria, not merely a convenience layered on top of them.conf: high
- implicitSoftware quality decays without active maintenance, which is why REA reviews systems on a recurring (quarterly) cadence rather than certifying them once.conf: medium
- implicitThe three lenses are largely independent axes of quality — a system can score well on one and poorly on another (e.g. well-architected but with an unclear testing strategy) — which the tiered per-lens rating structure assumes without ever stating it.conf: medium
- implicit'Good software' is an inherently contested, evolving judgment rather than a fixed specification — the criteria themselves are expected to be revised through ongoing debate, not treated as permanently settled.conf: medium
Arguments
Software at REA should be assessed and driven toward change using exactly three named lenses (dev, ops, arch) rather than a single good/bad judgment or a longer list of many narrow categories. strength: medium
Explicit premises:
- REA's software spans very different types of systems (internal tools, high-traffic mobile apps, big-data engines) with different functional/non-functional requirements.
- Despite this variety, there is a consistent underlying set of expectations and architectural principles across all of them.
- Capturing that shared consensus in succinct, high-level categories creates a foundation for discussion regardless of team, technology or timeframe.
Implicit premises:
- A workable assessment framework must generalize across heterogeneous systems while staying concrete enough to drive real decisions — three broad, named lenses hit that balance where a single universal metric would be too vague and dozens of narrow ones too granular to sustain as a shared vocabulary.
- Giving the underlying philosophy short, memorable names ('dev,' 'ops,' 'arch') has organizational value independent of the content behind them — it lets otherwise disparate teams have the same conversation.
Inferences:
- Because each lens is phrased as a question from the perspective of someone encountering the system anew ("Can I setup...", "Can I deploy..."), the framework implicitly optimizes for onboarding and handoff — for a newcomer's or successor's experience of the system — more than for the original author's experience while building it.
The application custodianship model — distributed authorship via pull requests but centralized architectural accountability in a single owning team — is the right way to govern software quality at REA's scale. strength: medium
Explicit premises:
- All systems are internally open source; any team may submit a change via pull request.
- The application custodian nonetheless owns the architecture, technical decisions and quality of the system, and their approval is required for any major change.
- Custodians perform the quarterly review and produce the health rating.
Implicit premises:
- Distributed authorship and centralized accountability are compatible because architectural integrity is actually protected at the approval gate, not the authorship gate.
- Someone must be accountable for a system's health or the published criteria remain aspirational rather than enforced — evidenced by the framework itself listing 'custodian assigned but not performing the role' as a failure mode.
Inferences:
- This implies architecture ownership is fundamentally a people/accountability problem before it is a technical one: the same written criteria produce different real-world outcomes depending purely on whether an accountable custodian is actively exercising the role.
Narratives
- REA's own 20-year history: from a single language (Perl) to a polyglot stack, from a garage-sized team to hundreds of engineers across continents, from ad-hoc servers to data centres to cloud.
→ Makes the 'why now' of the three big changes (micro-services, devops, application custodianship) causally legible as organic adaptation to scale, rather than a top-down fashion choice — supports the propositions about devops-as-enabler and microservices-as-response-to-monolith-pain. - The image of old monolithic systems that "typically could only be tested (manually or automatically) with specific versions of their monolith friends."
→ A vivid, concrete stand-in for the abstract case against tight coupling — instead of arguing for loose coupling in the abstract, it shows the specific pain (version-coordinated, fragile testing across coupled monoliths) that the arch lens's 'loosely coupled' criterion is designed to prevent.
Questions addressed
- ✅ What does 'good software' mean across radically different types of systems (internal tools vs. high-traffic consumer apps vs. big-data processing engines)?
Operationalized (not philosophically settled) via the three-lens framework with tiered, bulleted criteria that apply regardless of the system's type or technology. - ✅ How do you keep architectural quality from decaying once a system has shipped?
Periodic (quarterly) custodian review against fixed criteria, producing a tracked health rating. - ✅ How do you reconcile open internal collaboration (any team can submit a pull request) with the need for a single point of architectural accountability?
The custodian retains sole approval authority for major changes regardless of who authored the pull request. - ✅ Should quality and security be first-class lenses of their own, alongside dev/ops/arch?
Explicitly debated and rejected — folded into the existing three lenses as cross-cutting concerns, while arch itself is retained as a separately called-out lens despite also being cross-cutting. - ⭕ Does human review capacity (custodians performing quarterly reviews) scale as the number of systems and teams grows?
Gaps
- incompleteNo account of how the criteria themselves get updated over time, who has authority to add, remove or revise a bullet, or how a team's disagreement with a criterion (e.g. believing a 'falls significantly short' item doesn't fit their context) gets resolved.
Read next: Living/evolving internal standards literature — lightweight governance models such as RFC processes or ADR-based amendment for engineering guidelines themselves, not just for individual system decisions. - incompleteNo description of what happens after a 'falls significantly short' rating — whether there is a mandated remediation timeline, escalation path, or protected budget, versus the rating simply being visible ('feeds into a number of activities') with no forcing function.
Read next: Platform-engineering / internal-tooling writing on whether visibility-only metrics and dashboards actually drive remediation, or whether they need an attached forcing function to matter. - incompleteNo cost accounting for the review process itself — the custodian-time cost of quarterly reviews across what the piece implies are hundreds of systems is never mentioned, an interesting omission for an organization that otherwise frames its practices in terms of barriers and cost.
Read next: Organizational-debt literature on the overhead cost of governance and measurement processes themselves, not just the systems they measure. - uninformedWriting in 2018, the piece obviously predates AI coding agents; but its dev and arch criteria (readability, single responsibility, short feedback loops, testability, well-defined interfaces) turn out to be close to exactly the properties later work identifies as what AI agents most need from a codebase to work well — a use case the article had no way to anticipate.
Read next: Pair with extract-agents-dont-know-what-good-looks-like and extract-software-design-in-the-agentic-age to see how REA's same three lenses would need to change (or wouldn't) if the 'engineer confidently making changes' in the dev-lens question is an AI agent rather than a human.
Closes gaps elsewhere
- The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices · g4 — REA's arch lens is a concrete governance answer to whether periodic review is sufficient insurance against ad hoc microservice extraction producing a 'distributed monolith': a named custodian per system plus a tiered rubric that explicitly flags circular dependencies, shared-library reuse, and multiple sources of truth as 'falls significantly short' — a recurring, criteria-based check rather than a one-off architecture review.
Related documents
- The Organization Is the Bottleneck
- Software Design in the Agentic Age: Place Your Bets
- AI Is Changing Software Engineering. The Fundamentals Still Matter.
- CannotMeasureProductivity
- Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers
- Code maintainability plummets in the AI coding era
- AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action
- Fragments: July 6
- The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices
- Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase