Grado azul

El principio YAGNI (No lo vas a necesitar) es uno de los principios más sencillos del desarrollo de software y, sin embargo, probablemente el que se viola con más frecuencia después del principio DRY. Por eso YAGNI no sólo está al principio del grados rojospero también aquí hacia el final del camino a través del Sistema de valores.

El principio YAGNI se debe a la especial relación entre la precisión de los requisitos y la materialidad del producto en el desarrollo de software. Los requisitos son notoriamente imprecisos o cambiantes y el producto en el que deben materializarse es inmaterial. En comparación con la ingeniería mecánica o la construcción de edificios, el material es por tanto infinitamente flexible y puede, en principio, adaptarse a prácticamente cualquier requisito con comparativamente poco esfuerzo. Por tanto, una gran volatilidad o imprecisión se une a una gran flexibilidad. En principio, esto parece ideal.

Sin embargo, la práctica demuestra que es precisamente en esta relación donde está el germen del fracaso de muchos proyectos. A corto plazo, los proyectos intentan hacer lo correcto haciendo lo obvio:

• Los requisitos imprecisos suelen compensarse con productos que intentan suplir la imprecisión. La inmaterialidad del software se aprovecha para aplicarlo de forma tan amplia y flexible que incluso los requisitos desconocidos o imprecisos se cumplen por anticipado.
• Los requisitos, que cambian constantemente, se actualizan en el producto con la mayor rapidez posible, ya que esto es posible gracias a su inmaterialidad.

A largo plazo, sin embargo, este comportamiento es contraproducente:

• La obediencia anticipada conduce a una amplitud y flexibilidad que no son realmente necesarias. Realiza prestaciones que no se utilizan.
• Las rápidas modificaciones del software debidas a la evolución de los requisitos provocan una erosión de la calidad del código. Aunque el software es inmaterial y flexible, no toda estructura de software es evolucionable ni siquiera comprensible.

Las situaciones de requisitos poco claros y cambiantes en el contexto de la gran flexibilidad fundamental del software conducen rápidamente a gastos innecesarios y a un código frágil. Un gran número de proyectos que han superado sus límites presupuestarios y un número aún mayor de proyectos que se han vuelto imposibles de mantener al cabo de pocos años son testimonio elocuente de ello.

Los CCD, como desarrolladores profesionales de software, consideran su deber contrarrestar a diario estos avances. Dada la innegable naturaleza del software -es y sigue siendo inmaterial-, el planteamiento consiste en hacer frente a los requisitos. Este es el origen del principio YAGNI.

El principio YAGNI es como un cuchillo afilado: si lo utilizas, cortas un problema en pequeños cubos de lo inmediatamente necesario. Según el principio YAGNI, sólo se aplica lo que es incuestionable e inmediatamente útil. Todo lo demás... bueno, eso viene después. En este sentido, el YAGNI va de la mano de la regla "decidir lo más tarde posible" del Desarrollo ajustado de software.

El principio YAGNI es pertinente en todos los niveles de desarrollo de software y en todas las fases. Siempre que te preguntes: "¿Debería hacer este esfuerzo?" o "¿Realmente lo necesitamos?", aunque sea de forma tímida y silenciosa, estarás aplicando el principio YAGNI. Dice: "En caso de duda, decide no hacer el esfuerzo".

Parece fácil, pero es difícil. De ahí las frecuentes infracciones. Hay muchas fuerzas que contradicen la decisión de no esforzarse. "Oh, no es tanto esfuerzo" o "Si no miramos ahora hacia adelante, no podremos hacer nada más en el futuro" son dos justificaciones obvias del esfuerzo, aunque existan dudas sobre sus beneficios. Esto se aplica a las decisiones arquitectónicas (por ejemplo, ¿deberíamos empezar ya con una arquitectura distribuida, aunque la carga actual aún no la necesite?) y a las decisiones locales (por ejemplo, ¿debería optimizarse el algoritmo ahora, aunque actualmente no esté causando ningún problema de rendimiento?)

El cliente sólo paga por los beneficios directos. Lo que hoy no puede especificar con claridad no le sirve de nada. Por tanto, intentar anticiparlo en la fase de ejecución supone invertir esfuerzos sin generar beneficios. Cuando más adelante el cliente sepa exactamente lo que quiere, entonces -¡y no antes! - es el momento de satisfacer sus deseos. Sin embargo, siempre que un proyecto intenta anticiparse a esta voluntad, corre el riesgo de verse contradicho por la realidad de la voluntad del cliente mañana. Una prestación -funcional o no funcional- que se implanta hoy sin un requisito claro puede dejar de interesar al cliente mañana. O puede que ya no sea tan importante para ellos como otra característica.

Esto significa para el desarrollo de software:

• Aplique únicamente requisitos claros.
• El cliente prioriza sus requisitos claros.
• Aplique los requisitos claros en el orden en que se han priorizado.
• Establecer el proceso de desarrollo y la estructura del código a gran y pequeña escala de tal forma que no haya miedo a darse cuenta de los cambios y los nuevos requisitos.

Como desarrolladores profesionales, CCD comunica claramente este enfoque al cliente. Esto hace que:

• dispuestos a prestar el servicio, porque no tienen que rechazar al cliente una solicitud clara
• Responsables, porque sólo utilizan el presupuesto para prestaciones claramente formuladas
• protectoras hacia el código, porque lo protegen de ser sobrecargado con lo que a fin de cuentas es innecesario.

Por tanto, YAGNI no es sólo un principio que deba seguir todo desarrollador, sino también un principio para proyectos y equipos, es decir, a nivel organizativo. YAGNI debe tenerse siempre en cuenta, al igual que DRY. En caso de duda, aplaza la decisión si es posible. En caso contrario, decida en contra del esfuerzo. Esto relaja y agiliza y conduce más rápidamente al éxito.