Abraza las restricciones

Don't gloss over a routine or piece of code involved in the bug because you "know" it works. Prove it. Prove it in this context, with this data, with these boundary conditions.

— The Pragmatic Programmer, D. Thomas

La cita habla de depuración y contiene, casi de pasada, la mejor definición operativa de restricción que conozco. Fíjate en el final: this context, this data, these boundary conditions. Lo que hace que una afirmación sobre software sea verificable no es su generalidad, es su acotamiento. "Esto funciona" no se puede comprobar. "Esto funciona con este dato, en este contexto y en esta frontera" sí.

Es la misma operación que hace falta un nivel más arriba, cuando lo que se dirige no es una rutina sino un producto. Y es una operación que la industria evita con notable constancia, porque el material que manejamos nos permite evitarla.

Un material que no se resiste

Trabajar con software tiene una peculiaridad que conviene no naturalizar: el material no ofrece resistencia. Un carpintero descubre los límites de su proyecto al tocar la madera; la pieza tiene un grano, un tamaño y una tolerancia, y esas propiedades toman decisiones en su lugar. Un arquitecto tiene una parcela, un presupuesto de carga y una normativa. La resistencia del material es, en esos oficios, una fuente gratuita de restricciones.

En lo digital eso no existe. Casi todo es posible, nada se agota por sí solo, y añadir una posibilidad más rara vez impide técnicamente ninguna de las anteriores. Es la propiedad que hace del software una herramienta extraordinaria y la que convierte la dirección de producto en un oficio difícil: sin resistencia externa, no hay nada que fuerce una decisión. Y donde no hay decisiones no hay diseño, solo acumulación.

De ahí que las restricciones en producto digital tengan que ser impuestas, no encontradas. Es un trabajo deliberado, artificial y algo antipático, que consiste en fabricar la escasez que el material no proporciona. Cuando alguien dice que un equipo trabaja mejor con restricciones, no está haciendo un elogio del ingenio: está describiendo la única condición bajo la cual ese equipo puede terminar algo.

Las tres restricciones que hacen trabajo

No todas sirven igual. Hay tres que en mi experiencia hacen la mayor parte del trabajo, y las tres son incómodas por la misma razón: obligan a renunciar antes de tener información completa.

El tiempo fijo. Darle la vuelta al calcetín de la estimación —no cuánto tiempo necesita algo, sino cuánto tiempo le das— cambia el tipo de conversación que un equipo puede tener. Con tiempo abierto, la única pregunta disponible es qué falta por hacer. Con tiempo cerrado, aparece la pregunta que importa: qué es lo mínimo que tiene que existir para que esto sirva de algo. La segunda es una pregunta de diseño; la primera es una lista.

El perímetro. Decidir de antemano qué queda fuera es más barato que decidirlo cuando ya se ha construido. Y es más honesto, porque cuando se decide durante la construcción, lo que se recorta no es lo menos valioso: es lo último que quedaba pendiente, que es una categoría completamente distinta.

El apetito. Cuánto vale la pena gastar en esto, dicho antes de saber cuánto costaría. Suena imprudente y es lo contrario: es lo único que permite comparar iniciativas que no comparten unidad de medida. Sin apetito declarado, cualquier problema real justifica cualquier gasto, porque siempre es verdad que arreglarlo mejoraría algo.

Todas ellas son formas de la misma cosa. Estás fijando el contexto, los datos y las fronteras para que la pregunta sea contestable.

La tradición que ya lo sabía

Hay una genealogía larga detrás de esto y no es de gestión, es de oficio.

La filosofía Unix se construyó sobre una restricción radical —haz una sola cosa y hazla bien— que a primera vista parece una limitación y en la práctica fue lo que hizo posible la composición. Un programa que hace una cosa se puede combinar con otro; un programa que hace siete no se combina con nada. La restricción no redujo la potencia del sistema: la multiplicó, porque la trasladó del componente a la relación entre componentes.

Christopher Alexander llegó al mismo sitio desde el diseño: el problema de proyectar no consiste en imaginar formas, consiste en identificar el conjunto de exigencias que la forma debe satisfacer y las tensiones entre ellas. Sin ese conjunto acotado no hay criterio, y sin criterio la elección entre dos soluciones es estética o política, nunca funcional.

Ohno lo formuló en la fábrica desde una intuición contraria a la ortodoxia de su época: limitar el inventario no era una consecuencia de tener un buen proceso, era el mecanismo que obligaba a tener uno. Con inventario abundante, cualquier problema del sistema queda amortiguado y por tanto invisible. La restricción actúa como revelador.

Bruno Munari, escribiendo sobre diseño gráfico, decía algo aún más directo: los problemas bien planteados contienen ya su solución. El trabajo del proyectista está en el planteamiento, no en la inspiración. Y plantear consiste, precisamente, en restringir.

Lo que la cita pide de verdad

Volviendo a Thomas: el punto no es la disciplina de depuración, es la sospecha sobre lo que crees que sabes. Because you "know" it works — con las comillas puestas a propósito. La rutina que nunca revisas es la que contiene el error, no por mala suerte, sino porque el error sobrevive exactamente donde no se mira.

En dirección de producto el equivalente es la restricción que no se pone porque parece obvia. El supuesto de que este cliente se comporta como los demás. El supuesto de que este dato significa lo que su nombre indica. El supuesto de que el alcance acordado es el alcance real. Todos ellos son afirmaciones sin frontera, y todas las afirmaciones sin frontera son incomprobables.

Abrazar las restricciones no es una actitud frugal ni un elogio de la austeridad. Es aceptar que solo se puede decidir sobre lo que se ha acotado, y que en un material sin resistencia propia acotar es un trabajo que nadie va a hacer por ti.

¿Cuál de tus certezas sobre tu producto no has puesto a prueba porque parecía innecesario?