El proceso de calidad más eficaz que nadie usa
En 1976, Michael Fagan publicó un artículo en el IBM Systems Journal que describía un proceso de revisión tan eficaz que se convirtió en el estándar de oro para la calidad del software. Las Fagan Inspections capturaban del 60 al 90 por ciento de todos los defectos antes de que se ejecutara una sola prueba. Un estudio de la NASA en 2002 descubrió que cada hora dedicada a la inspección prevenía un promedio de 33 horas de trabajo de mantenimiento más adelante.
Según cualquier estándar medible, este fue el mejor proceso de revisión que la ingeniería de software jamás haya producido.
Casi nadie lo usa hoy.
La pregunta no es si las Fagan Inspections funcionaban. Funcionaban casi demasiado bien. La pregunta es por qué un proceso con ese historial desapareció del desarrollo convencional, y si perdimos algo importante cuando lo reemplazamos.
Cómo eran realmente las Fagan Inspections
Fagan no inventó el code review. Inventó un ritual específico y altamente estructurado para encontrar defectos.
El proceso tenía seis fases rígidas:
- Planning: Un moderador seleccionaba a los participantes y verificaba que el material cumpliera con los criterios de entrada.
- Overview: El autor explicaba el contexto. Esto servía para establecer el contexto, no para revisar.
- Preparation: Cada participante revisaba el material de forma independiente, a aproximadamente 150 líneas por hora, con una lista personal de defectos sospechados.
- Inspection Meeting: El equipo se reunía por no más de dos horas. Un reader narraba la lógica en voz alta. Un recorder registraba los defectos. El moderador mantenía la reunión enfocada en encontrar defectos, no en resolverlos.
- Rework: El autor corregía cada defecto registrado.
- Follow-up: El moderador verificaba que se hubieran realizado las correcciones y que no se hubieran introducido nuevos defectos.
Los roles eran específicos y no superpuestos. El moderador dirigía el proceso pero no era la autoridad técnica. El reader narraba el código pero no lo defendía. El autor estaba presente pero prohibido de explicar su intención durante la reunión. El propósito no era la colaboración. Era la detección fría y sistemática de defectos.
Esta es la parte que lo hacía funcionar. La dinámica social de las reuniones normales de ingeniería fue eliminada por diseño.
Por qué los números eran tan buenos
La tasa de detección de defectos no fue un accidente. Provino de algunas decisiones de diseño deliberadas.
La preparación independiente significaba que seis personas examinaban el mismo código de forma aislada antes de que cualquier discusión grupal pudiera sesgarlas. La superposición entre sus listas te decía qué tan obvio era un defecto. Los elementos que solo una persona encontraba a menudo eran los más valiosos.
El límite estricto de dos horas impedía que la fatiga destruyera el juicio. Fagan sabía que la efectividad de la inspección cae en picada después de aproximadamente dos horas. La tasa de 150 líneas por hora también fue deliberada. Si vas más rápido, empiezas a ver lo que esperas ver en lugar de lo que realmente está ahí.
La regla de no soluciones mantenía las reuniones enfocadas. Nada destruye una inspección más rápido que una sala llena de ingenieros diseñando una solución para un defecto que aún no han caracterizado por completo.
Estas restricciones no eran una carga burocrática. Eran el mecanismo. Si las eliminas, obtienes algo más amigable pero menos efectivo.
Qué mató a las Fagan Inspections
Si el proceso era tan efectivo, ¿por qué desapareció?
La respuesta corta es que era caro exactamente de la manera que el desarrollo de software moderno se niega a tolerar.
Una sola Fagan Inspection consumía del 15 al 20 por ciento del esfuerzo dedicado a escribir el código que se revisaba. En un caso documentado, 348 líneas requirieron 27,3 horas-persona de inspección. Esa proporción es inconcebible cuando los equipos hacen despliegues varias veces al día.
Solo la programación era un trabajo de tiempo completo. Necesitabas cinco o seis personas en una sala durante dos horas, más preparación, más tracing. En una organización grande, encontrar un espacio de dos horas donde un moderador, reader, dos revisores, recorder y autor estuvieran todos disponibles podía tomar días.
La estructura rígida de roles tampoco escalaba. Las Fagan Inspections asumían un equipo estable con suficientes personas para ocupar todos los roles. En una startup, un equipo de cinco personas podría no tener a nadie que pudiera servir como moderador dedicado sin destruir la velocidad.
El factor más grande fue cultural. Las Fagan Inspections eran deliberadamente incómodas. El autor se sentaba en silencio mientras sus colegas narraban su código y registraban sus defectos. No había espacio para “esto es solo un borrador”. El proceso asumía que los defectos son caros y la fricción social es barata. La ingeniería moderna opera bajo la suposición opuesta.
Con qué lo reemplazamos
La industria no abandonó la revisión estructurada. La reemplazó con pull requests.
La revisión de pull requests es asíncrona, de baja ceremonia, y embebida directamente en el workflow de desarrollo. Un revisor puede mirar un diff entre reuniones, en su teléfono, o mientras espera que termine CI. No hay roles asignados. El autor y el revisor a menudo son la misma persona que solo necesita una aprobación más para hacer merge.
Esto es una mejora masiva en accesibilidad, velocidad y developer experience. También es una regresión masiva en la detección de defectos.
Múltiples estudios encontraron que la revisión informal atrapa aproximadamente la mitad de los defectos que atrapa la inspección estructurada. Un experimento de 2009 de Basili y otros comparó la inspección estilo Fagan con la revisión lightweight y descubrió que el proceso más ligero capturaba significativamente menos defectos en el mismo material.
El problema no es que los revisores sean perezosos. El proceso no está diseñado para encontrar defectos. Está diseñado para permitir que la gente envíe código con un segundo par de ojos sobre él, lo cual no es lo mismo.
Qué perdimos realmente
La revisión de pull requests optimiza el throughput. La inspección Fagan optimizaba la exhaustividad. Estos son objetivos genuinamente diferentes, y ninguno está mal. El error es asumir que el proceso más ligero es un superconjunto estricto del más pesado.
Esto es lo que desapareció:
Preparación independiente. En un pull request, el revisor ve el diff de forma fría. No ha pasado una hora leyendo el contexto circundante, rastreando el flujo de datos y construyendo un modelo mental. Está reaccionando a una notificación. La profundidad del examen no es comparable.
El rol de reader. Hacer que alguien narre el código en voz alta obliga al grupo a avanzar a un ritmo que la persona más lenta puede seguir. Revela supuestos que la lectura silenciosa oculta. Un diff en una pantalla permite que tus ojos se salten las partes aburridas. Un reader no se salta nada.
Enfoque solo en defectos. Los comentarios de pull request derivan hacia opiniones de estilo y arquitectura. Estas son valiosas, pero no son detección de defectos. Cada minuto gastado debatiendo la indentación es un minuto no gastado encontrando un null dereference.
Datos de proceso medibles. Las Fagan Inspections producían números duros: defectos por hora, tiempo de preparación, tiempo de retrabajo, defect density por module. Las herramientas modernas de revisión cuentan comentarios y aprobaciones, que no te dicen casi nada sobre la calidad de la revisión.
Un punto medio práctico
No vas a ejecutar Fagan Inspections completas en un entorno de continuous deployment moderno. Pero puedes tomar prestadas las partes que importan.
La idea más importante transferible es la preparación independiente estructurada. Antes de una revisión async profunda, exige que los revisores pasen tiempo con el material solos. No una lectura rápida. Preparación real.
En lugar de un genérico “LGTM”, impón una checklist lightweight que imite la disciplina que Fagan construyó en roles y reglas:
from dataclasses import dataclass, field
from typing import List, Optional
from enum import Enum
class DefectSeverity(Enum):
MINOR = "minor"
MAJOR = "major"
CRITICAL = "critical"
@dataclass
class ReviewEntry:
line_number: Optional[int]
category: str
severity: DefectSeverity
description: str
@dataclass
class InspectionReport:
reviewer: str
prep_time_minutes: int
entries: List[ReviewEntry] = field(default_factory=list)
def defect_count(self) -> int:
return len(self.entries)
def run_inspection_checklist(
code: str,
reviewer: str,
prep_time_minutes: int
) -> InspectionReport:
"""Structured prep produces structured output.
Mimics the Fagan prep phase: reviewer spends focused
time with the material, then logs findings against a
consistent taxonomy instead of ad hoc comments.
"""
report = InspectionReport(
reviewer=reviewer,
prep_time_minutes=prep_time_minutes
)
# Example: check for missing null handling
if "->" in code and "null" not in code.lower():
report.entries.append(ReviewEntry(
line_number=None,
category="null-safety",
severity=DefectSeverity.MAJOR,
description="No explicit null handling in pointer function"
))
return reportEsto no es una Fagan Inspection. Es una forma de recuperar una de sus propiedades más importantes: el output de revisión debe ser estructurado, medible y enfocado en categorías de defectos en lugar de opiniones.
Otra idea transferible es la revisión profunda con límite de tiempo. Elige un module crítico por sprint. Programa una revisión enfocada de 90 minutos con preparación independiente. Registra solo defectos. No soluciones, no debates de estilo, no argumentos de diseño.
El costo es real. Pero si la proporción de la NASA se sostiene siquiera aproximadamente, una hora enfocada ahora ahorra docenas de horas de debugging más adelante.
La verdad incómoda
Las Fagan Inspections no fracasaron. Fueron rechazadas porque la rigurosidad que requerían era incompatible con la velocidad que la industria priorizaba.
Ese compromiso tenía sentido para mucho software. Un error tipográfico en un botón de una landing page no necesita una inspección formal de cinco personas. Pero la cultura que reemplazó a las Fagan Inspections trata todo el código de la misma manera, y ahí es donde se esconde el costo.
Los defectos más costosos están en el código que parece correcto, pasa las pruebas y falla en producción de maneras que cuestan dinero real. Ese es exactamente el código que más se beneficia de un proceso diseñado para encontrar defectos en lugar de un proceso diseñado para aprobar diffs.
La revisión de pull requests está aquí para quedarse, y eso está bien. Pero pretender que es un reemplazo para la inspección estructurada no está bien. Es una herramienta diferente para un trabajo diferente, y los equipos que solo poseen una de ellas seguirán encontrando bugs costosos que un mejor proceso habría detectado antes del despliegue.
FAQ
¿Qué es una Fagan Inspection?
Un proceso de revisión estructurado y multietapa para encontrar defectos en artefactos de software, desarrollado por Michael Fagan en IBM en la década de 1970. Involucra seis fases (Planning, Overview, Preparation, Inspection Meeting, Rework, Follow-up) con roles específicos para los participantes. La reunión se enfoca exclusivamente en registrar defectos, no en resolverlos.
¿Qué tan efectivas eran las Fagan Inspections?
IBM reportó tasas de eliminación de defectos superiores al 90 por ciento. Un estudio de la NASA en 2002 encontró que cada hora de inspección prevenía un promedio de 33 horas de mantenimiento. Estudios independientes encontraron consistentemente que la inspección estructurada atrapa aproximadamente el doble de defectos que la revisión informal.
¿Por qué los equipos dejaron de usar las Fagan Inspections?
El proceso consumía del 15 al 20 por ciento del esfuerzo total del proyecto, requería una programación difícil de múltiples participantes, y era culturalmente rígido. A medida que los equipos de software se movieron hacia ciclos de release más rápidos, el overhead se volvió insostenible. La revisión de pull requests lo reemplazó como el default porque es más rápida y fácil de integrar en el workflow normal, aunque atrapa menos defectos.
¿Pueden los equipos modernos beneficiarse aún de las Fagan Inspections?
No en la forma original. El proceso completo de seis fases con roles asignados no encaja en el continuous deployment. Pero las ideas centrales — preparación independiente, revisión enfocada con límite de tiempo, registry estructurado de defectos, y separar la búsqueda de defectos del diseño de soluciones — pueden adaptarse. Los equipos que aplican esto selectivamente al código crítico obtienen gran parte del beneficio sin el overhead.