¿Que es la Fragilidad del software ?

Supón que sigues todas las guías de estilo, eres «clean», cuidadoso, fiel seguidor de TDD, conoces tu plataforma, … pero, aun así, por una extraña razón, con el tiempo tu sistema se tambalea, pues es aqui donde entra un concepto bastante interesante llamado la fragilidad del software el cual representa una propiedad global de un sistema (de software), pero no de lo bien o mal que funciona, sino de la capacidad del mismo para adaptarse a algún cambio.

Un sistema puede ser muy robusto, tolerante a fallos, rápido, ... y, aun así, ser tremendamente frágil. Clic para tuitear

Si definir la fragilidad del software resulta bastante sencillo (tolerancia al cambio), determinar y/o identificar sus causas resulta tremendamente complicado ya que existen innumerables razones por las que un sistema se vuelve frágil, pero además, dichas razones están con frecuencia interrelacionadas (enrevesadas mas bien) de modo que, por ejemplo, alguien podría pensar que un sistema es más frágil cuanto más tiempo transcurre sin mantenimiento (por ejemplo, porque la plataforma de desarrollo evoluciona y debe guardarse, recuperarse o reinstalarse una versión acorde a dicho sistema), pero no es menos cierto el recíproco, que un sistema es más frágil cuanto más modificaciones sufre (por ejemplo, si no mantenemos la probabilidad de detectar y corregir por encima de la de introducir errores, los errores, sólo pueden aumentar con el tiempo).

Por el ejemplo primero queda claro que no es suficiente con «no tocar nada» para que no aumente la fragilidad de nuestro software (¡aumentará aunque no modifiquemos nada!) y por el segundo que la fragilidad aumentará o disminuirá de acuerdo a un complicadísimo juego de malabares entre una aparente infinidad de factores interrelacionados (enrevesados).

¿Cómo minimizar la fragilidad de mi sistema?

La respuesta fácil es enumerar términos como clean, TDD, KISS, patrones, microservicios, … pero son sólo técnicas, manifiestos, guías, … basados en la experiencia y que pueden o no encajar con nuestro contexto particular.

Obviamente usar buenas prácticas parece adecuado, pero no hay que olvidar que;

una buena práctica mal usada se convierte rápidamente en una pésima práctica. Clic para tuitear

Parece entonces que hay «algo» por encima de esas prácticas que debería poder hacerse de las cuales yo veo dos sobre otras (que habrá, que yo desconozco y que puede sean más relevantes): la experiencia y sentido común de quien aplica las soluciones.

Lo vi en http://www.genbetadev.com