Fred Brooks: Lo difícil nunca fue teclear

9 min de lectura

La pantalla funcionaba. Faltaba el acuerdo.

Él mismo había dirigido aquel caos

Fred Brooks contribuyó a definir el System/360 de IBM y dirigió el trabajo de su sistema operativo OS/360. Su visión del desarrollo de software nació de esa experiencia. En su entrevista de historia oral con Grady Booch de 2007, recuerda que Thomas Watson Jr. le preguntó en qué se diferenciaba dirigir proyectos de hardware y de software. Reflexionar sobre aquella pregunta fue el punto de partida de The Mythical Man-Month.

La entrevista también contiene algo más útil que un resumen heroico de su carrera. Cuando le preguntan por su peor decisión, Brooks cuenta que transfirió la responsabilidad de la arquitectura del grupo de arquitectura al responsable del sistema operativo. Reconoce su propio error. Quien explicaba por qué fracasan los proyectos de software había contribuido al fracaso de uno.

Eso lo convierte en un compañero útil cuando aparece otra herramienta impresionante que insinúa que la parte difícil por fin ha desaparecido. Nos permite examinar el trabajo que queda detrás de la promesa.

Dos tipos de dificultad y una confusión muy cómoda

En No Silver Bullet, su ensayo de 1986, Brooks separó la dificultad esencial —el trabajo conceptual de especificar, diseñar y comprobar un sistema— de la dificultad accidental de representar esos conceptos en código y comprobar que el código los expresa fielmente. Identificó cuatro problemas persistentes: complejidad, necesidad de ajustarse a otros sistemas e instituciones, mutabilidad e invisibilidad. Su pronóstico era que ningún avance técnico o de gestión, por sí solo, multiplicaría por diez la productividad, la fiabilidad o la simplicidad en una década. Eso no mide las capacidades de la IA actual.

Ese trabajo conceptual incluye relaciones entre datos, algoritmos e interacciones entre las partes del sistema. Acordar una regla de negocio inicia el trabajo de diseño. No lo termina.

Pensemos en un mayorista inventado que sustituye los pedidos por teléfono por un servicio en línea. Crear el formulario puede resultar sencillo. Decidir cuándo un pedido se convierte en una promesa es otra cosa.

Ventas interpreta la confirmación como un compromiso. El almacén la trata como una solicitud hasta que se asignan las existencias. Finanzas la considera provisional hasta comprobar la solvencia del cliente. Los tres departamentos pueden demostrar que su interpretación lleva años funcionando. Los tres también pueden señalar al compañero que resuelve discretamente los casos incómodos.

Ahora el software necesita una regla. El criterio de ese compañero debe convertirse en una decisión explícita, una excepción con un responsable o un motivo para mantener parte del trabajo manual. El desarrollador que pregunta por esto ha descubierto en qué consiste su trabajo. Pedirle que deje de darle tantas vueltas y termine el formulario solo garantiza que la suposición de otro se imponga por defecto.

El código puede estar bien escrito. La promesa puede seguir siendo errónea.

La excepción forma parte del producto

Ahora el cliente cancela cuando ya ha empezado la preparación del pedido. Pulsa el botón mientras un trabajador del almacén camina hacia la estantería. ¿Debe desaparecer el pedido de su dispositivo? ¿Debe el trabajador confirmar primero la cancelación? ¿Qué debe ver el cliente mientras esa confirmación está pendiente?

Supongamos que se pierde la conexión del almacén. El cliente ha recibido una confirmación de cancelación, pero el trabajador sigue preparando pedidos de una lista descargada. Un transportista recoge el paquete. La empresa acaba de enviar un pedido que había confirmado al cliente como cancelado.

Estas preguntas afectan tanto a la implementación como al negocio. Determinan transiciones de estado, registros almacenados, mensajes, reintentos y la pantalla que utilizará quien intente reparar el error. El desarrollador necesita conocimientos técnicos suficientes para hacer visible el fallo y acceso a las personas implicadas para acordar una respuesta aceptable.

Alguien podría proponer una regla comercial más sencilla: una vez iniciada la preparación, la cancelación pasa a ser una solicitud, y el cliente ve esa diferencia inmediatamente. La decisión podría eliminar varios problemas técnicos. También cambia el servicio que ofrece la empresa. Los responsables de ese servicio deben aceptarla.

Incluso con ese acuerdo, el diseño sigue teniendo trabajo pendiente. ¿Qué cuenta como inicio de la preparación: que el trabajador toque la estantería, que el dispositivo registre la acción o que el servidor la acepte? ¿Qué ocurre cuando la preparación y la cancelación llegan juntas al servidor? Comprobar que un pedido sigue en espera y cancelarlo después deja un intervalo en el que puede comenzar su preparación. El sistema debe resolver esa carrera de forma coherente, incluido lo que puede hacer un trabajador sin conexión antes de recuperarla.

Por eso una excepción merece más atención de la que a veces sugiere la expresión «caso límite». El recorrido habitual permite que varias ideas incompatibles convivan pacíficamente. La excepción hace que se encuentren.

Un prototipo puede mejorar el razonamiento

Brooks defendía afinar los requisitos mediante prototipos y hacer crecer el software en funcionamiento de manera incremental. Proponía una vía práctica para aprender, en lugar de exigir que todo el razonamiento terminara antes de programar. Esa recomendación importa tanto como la famosa advertencia sobre herramientas milagrosas. El ensayo original contiene ambas.

Para el mayorista, construye la versión mínima que exponga el problema de la cancelación. Una persona hace un pedido de prueba mientras otra empieza a prepararlo. Cancélalo a mitad del proceso. Interrumpe la conexión del almacén. Pregunta a ambas personas qué creen que ha sucedido y compara sus respuestas con los registros del sistema.

El primer resultado útil puede ser una conversación incómoda. Bien. Ocurrió antes de que la empresa importara diez mil clientes y anunciara que había transformado la manera de hacer pedidos.

Cuando los participantes acuerden el comportamiento, recoge ejemplos concretos en comprobaciones automatizadas. Incluye la cancelación tardía, la llegada simultánea de preparación y cancelación, la pérdida de conexión y un mensaje repetido. Haz que un cambio pequeño pase por integración y llegue a una versión en uso, para que el equipo descubra problemas en su entorno real. La disciplina de feedback de Kent Beck ofrece un complemento útil: aprender mientras el cambio sigue siendo lo bastante pequeño para comprenderlo.

El trabajo ha avanzado cuando las personas pueden explicar y demostrar qué ocurre. El número de pantallas es un sustituto bastante pobre.

La IA puede ayudar más allá de teclear

Aplicar la distinción de Brooks a la IA exige cierto cuidado. Un asistente puede ayudar a formular alternativas, rastrear una implementación existente, detectar reglas contradictorias y sugerir experimentos. Esas actividades pueden contribuir al trabajo conceptual. Tratar toda aportación de la IA como mero tecleo dejaría fuera buena parte de su posible valor.

En el ejemplo de la cancelación, dale al asistente las restricciones acordadas y pídele que rastree dónde afecta actualmente la cancelación a las existencias, el pago y la expedición. Pregunta qué ocurre si cada mensaje llega dos veces o fuera de orden. Pídele que compare la cancelación inmediata con una solicitud de cancelación y describa quién soporta las molestias en cada diseño. Contrasta sus respuestas con el código fuente, las interfaces reales y las personas que gestionan los pedidos.

Un asistente también puede crear un prototipo que facilite discutir esas alternativas. Una implementación barata se vuelve valiosa porque permite al equipo probar una idea sobre la que antes solo podía discutir.

Pero una respuesta plausible no tiene autoridad para cambiar los derechos de un cliente ni las responsabilidades de un trabajador del almacén. Si el asistente rellena un vacío con una convención conocida, esa convención sigue siendo una propuesta. El código en funcionamiento puede ocultar la suposición con tanta eficacia como un párrafo seguro de sí mismo.

La frontera útil está entre una propuesta y las pruebas de que encaja. Cruzarla sigue exigiendo contacto con el sistema y con las personas cuyo trabajo cambia.

La complejidad también debe justificarse

Llamar esencial a un problema puede convertirse en otra excusa. Quizá el mayorista tiene seis reglas de cancelación porque seis antiguos responsables negociaron acuerdos especiales. Quizá existen dos interfaces solo porque nadie retiró una importación antigua. Conservar cada complicación heredada convertiría el nuevo software en un museo inusualmente caro.

Pregunta qué compromisos son reales, qué restricciones siguen vigentes y qué procedimientos está dispuesta a cambiar la empresa. A veces la mejor simplificación técnica empieza eliminando una excepción de negocio. Otras veces la regla incómoda protege una relación valiosa con un cliente y debe quedarse. La respuesta exige investigar. El código elegante no puede darla por sí solo.

Eso también deja espacio para mejoras corrientes y considerables. Una biblioteca mejor, un entorno de desarrollo reparado o un asistente que se ocupe de cambios repetitivos pueden ahorrar mucho trabajo tedioso. La provocación del título tiene un límite: implementar tiene costes reales, y reducirlos importa. El error consiste en suponer que ese ahorro resuelve todas las demás clases de trabajo.

Mary Poppendieck hizo visible un problema relacionado: acelerar una actividad puede dejar lento el recorrido completo. Aquí, la restricción sin resolver puede ser un acuerdo sobre qué debe prometer el software.

¿Qué incertidumbre has eliminado?

De vuelta al mayorista, el botón de cancelación distingue ahora entre un pedido cancelado y una solicitud pendiente de confirmación del almacén. Un trabajador sin conexión recibe la solicitud al recuperarla; hasta que el almacén confirma que se ha detenido el pedido, el cliente ve la cancelación como pendiente. Alguien se ocupa de resolver las solicitudes que siguen sin respuesta. Finanzas puede rastrear cualquier ajuste de pago resultante. El equipo ha probado esas transiciones conjuntamente, incluido lo que ocurre cuando compiten la preparación y la cancelación.

Esa versión puede contener menos funciones que la primera demo. Contiene una respuesta mucho mejor.

Brooks merece otra lectura cada vez que la industria confunde una implementación más fácil con haber terminado de entender el problema. Su argumento invita a plantear una pregunta ante cada nueva herramienta y cada nuevo cambio: ¿qué parte de la dificultad ha eliminado esto realmente?

Si la respuesta es trabajo repetitivo de implementación, disfruta del ahorro. Si es una suposición descubierta y corregida, mejor aún. Si nadie sabe decirlo, quizá la demo simplemente se haya vuelto más convincente.

El almacén acabará preguntando de todos modos.