The Team That Deletes Features#
In 2004, a team of engineers at Google building the initial version of Gmail faced a decision about attachment handling. The existing standard in email — both in Microsoft Outlook's protocol handling and in web-based email clients — was to embed attachment metadata in a complex MIME structure that could represent multiple levels of nesting, alternative content types, and encoding variants. Implementing the full MIME specification would have required significantly more code, more edge-case handling, and considerably more testing surface than a simplified alternative.
The Gmail attachment implementation chose the simplified alternative. Rather than implement the full MIME nesting specification, the team implemented the common case — a single level of attachments with well-defined content types — and deferred full MIME tree support until later. The decision meant that some email clients that sent unconventionally structured MIME documents would have attachment rendering failures in early Gmail. The decision also meant that the attachment parsing code was small enough to be fully reviewed, fully understood, and fully tested by the team that built it.
This is the CRIP management decision in practical form: accepting incomplete feature delivery in return for staying below the complexity threshold where the codebase is cognitively manageable. The decision is not dramatic. It is not heroic. It is unglamorous. Its consequences are felt most clearly by the users who experience the edge-case failures — the users whose attachments don't render correctly — and are invisible to users whose attachments work fine. The organisational discipline to make this decision consistently — to refuse features that would cross CRIP, to accept the visible cost of the refused feature rather than the invisible risk of the crossed CRIP — is rare.
The Disciplines of Below-CRIP Design#
Complexity Budgets#
The most direct institutional mechanism for CRIP management is a complexity budget — an explicit numerical limit on the complexity of a subsystem that must be approved to increase and enforced through design review authority. Amazon Web Services applies service complexity budgets through its "two-pizza team" principle: Amazon services should be operated by teams small enough to be fed by two large pizzas. The constraint is not primarily about team size; it is about service interface complexity. A service that requires more than a small team to understand and operate is a service that has crossed its operational CRIP. The two-pizza constraint enforces complexity management by making CRIP-crossing services organisationally expensive.
Netflix's microservices decomposition — breaking what was a monolithic video streaming application into hundreds of independent services — was motivated primarily by deployment independence and fault isolation, but it had a secondary CRIP management effect: each service's complexity is bounded by its functional scope, and failures in one service cannot propagate through shared state to others. The circuit breaker pattern used extensively in Netflix's Hystrix library (now largely replaced by resilience4j) explicitly prevents cascading failures by monitoring inter-service call failure rates and "opening the circuit" — returning a defined fallback response rather than queuing calls into an overloaded service. This is CRIP management built into the inter-service communication architecture.
Interface Minimisation as a Safety Discipline#
Aviation's contribution to CRIP management literature is the concept of independence: in airworthy system design, two systems that must not produce correlated failures are engineered to have minimal interfaces. The FAA's Advisory Circular 25.1309 — which governs the safety analysis of aircraft systems — requires that for systems whose combined failure would be catastrophic, they must be independent to the extent that a single failure (or single maintenance error) cannot simultaneously affect both. The independence requirement is a regulatory CRIP management tool: it limits the interface surface between high-consequence systems, preventing the interaction complexity that generates CRIP-crossing failure modes.
The 737 MAX MCAS architecture violated this principle in the original design: a single sensor feeding the only redundancy-less input to a system that could command nose-down trim without pilot override was not independent of the AoA sensing system in the way that FAA 25.1309 analysis would typically require for a system with authority over aircraft attitude. The independence analysis was bypassed because MCAS was initially characterised as a low-severity system — a characterisation that was not revised when the system's authority was later doubled.
Designing strictly to independence requirements for high-consequence systems is a form of mandatory complexity limitation. It prevents the architectural compromises — shared sensors, shared actuators, shared data buses — that reduce manufacturing cost at the price of CRIP-crossing interaction modes.
Simplicity as an Explicit Design Criterion#
The most effective organisations for CRIP management treat simplicity as a first-class design criterion — not a secondary consideration to be traded against functionality, but a value whose cost is explicitly accounted for and whose benefits are claimed in design review. This is, culturally, a difficult stance to maintain. Engineering culture tends to reward the addition of capability and to view the removal of features as failure or compromise. The CRIP framework provides a basis for arguing, in engineering terms, that below-CRIP simplicity is not a compromise — it is a safety parameter.
The Linux kernel's documentation includes an explicit note from Torvalds on the value of code deletion: "the best code is no code." The statement is an engineering principle, not a philosophical one. A line of code that does not exist cannot have a bug. An interface that does not exist cannot have an injection point for a cascading failure. A feature not implemented cannot generate CRIP-crossing interaction modes with other features. The discipline of deleting code, refusing features, and enforcing interface minimalism is the discipline of staying below CRIP — and it is as applicable to medical protocol systems and aviation certification processes as it is to software.
What Below-CRIP Organisations Have in Common#
The organisations that have maintained below-CRIP operations at large scale share a consistent set of structural properties. They have explicit authorities empowered to refuse complexity: Linux subsystem maintainers who can reject complex patches; Amazon service architects who can refuse service scope expansion; aviation type certification teams who enforce independence requirements. These authorities exist outside the commercial pressure to deploy features quickly, and they have demonstrated willingness to exercise their authority against schedule pressure.
They have feedback mechanisms that measure complexity rather than only functionality. Code review metrics, interface dependency analysis, FMEA scope coverage, and alarm fatigue monitoring are examples from different domains — each provides a signal about the system's proximity to CRIP that is distinct from the functionality metrics that tell management the system is working.
They have cultures that treat CRIP-crossing as a first-class risk — not a technical debt to be deferred, not an acceptable trade-off for capability, but a condition that makes the system's failure modes unpredictable. This cultural stance requires understanding that the catastrophic consequences of CRIP-crossing are not proportional to the apparent severity of the feature that crossed it. The 737 MAX's MCAS was a small feature. The Challenger O-ring was a small component. The Columbia foam strike was a known minor debris event. What made them catastrophic was not their individual severity — it was their position at the interface of systems complex enough to amplify small initiating events into unrecoverable consequences.
Designing below CRIP is not an exercise in restriction. It is an exercise in understanding which interfaces are load-bearing, which interactions are manageable, and where the boundary lies between a system that humans can operate safely and one that has grown beyond the capacity of any organisational structure to manage well.
