Fragilidad del software ¿En qué estoy fallando?

Supón que prosigues todas y cada una de las guías de estilo, eres clean, cauteloso, leal seguidor de TDD, conoces tu plataforma, … mas, incluso de esta manera, por una extraña razón, con el tiempo tu sistema se tambalea, o bien debes perder bastante tiempo en refactorizar, o bien el número de tests hace que tus despliegues retarden horas, o bien cada vez te resulta más confuso ver la mejor manera de introducir mejoras, … ¿qué ha fallado?

No hablo de cuando se hacen las cosas mal (en que es aproximadamente obvio que tarde que temprano se pierda el control), hablo de cuando las cosas se hacen bien o bien, por lo menos, se han seguido los cánones marcados por la industria. No es inusual perder el control de un proyecto y ocurre en una enorme pluralidad de campos, equipos grandes o bien pequeños, en grandes y pequeñas empresas, con recursos y sin recursos.

¿Qué es la debilidad del software?

La debilidad del software representa una propiedad global de un sistema (de software), mas no de lo bien o bien mal que marcha, sino más bien de la capacidad del mismo para amoldarse a algún cambio. De este modo, un sistema puede ser realmente robusto, tolerante a fallos, veloz, … y, incluso de este modo, ser formidablemente débil. Si cuando de un sistema que marcha bien (razonablemente, bien o bien realmente bien) se afirma mejor no tocarlo, es por el hecho de que ese sistema es débil.

La debilidad del software da idea de la capacidad de un sistema de software para amoldarse a algún cambio

Si acotar la debilidad del software resulta bastante fácil (tolerancia al cambio), determinar y/o identificar sus causas resulta formidablemente complicado en tanto que existen incontables razones por las que un sistema se vuelve débil, mas además de esto, dichas razones están habitualmente interrelacionadas (complicadas pero bien) de forma que, por servirnos de un ejemplo, alguien podría meditar que un sistema es más débil cuanto más tiempo transcurre sin mantenimiento (por servirnos de un ejemplo, pues la plataforma de desarrollo evoluciona y debe guardarse, recobrarse o bien reinstalarse una versión acorde a dicho sistema), mas no es menos cierto el recíproco, que un sistema es más débil cuanto más modificaciones padece (por poner un ejemplo, si no sostenemos la probabilidad de advertir y corregir sobre la de introducir fallos, los fallos, solo pueden acrecentar con el tiempo).

Por el ejemplo primero está claro que no es suficiente con no tocar nada a fin de que no aumente la debilidad de nuestro software (¡va a aumentar si bien no alteremos nada!) y por el segundo que la debilidad va a aumentar o bien reducirá conforme a un complicadísimo juego de malabares entre una aparente infinidad de factores interrelacionados (complicados).

no es suficiente con no tocar nada a fin de que no aumente la debilidad de nuestro software

¿Exactamente en qué me afecta la debilidad del software?

Primeramente decir que, el que no te sientas perjudicado (no percibas síntomas de debilidad en tus softwares) es ya un síntoma de que (tal vez) estés ignorando la debilidad del software, en el sentido de que puedas estar despilfarrando recursos (muy seguramente), sin embargo, es indudablemente el mejor punto del que partir (siempre y cuando ese dispendio sea asumible).

No obstante generalmente (con salvedades como es natural) y en todo género de países y empresas (ojo, en mi subjetiva experiencia), los sistemas débiles están a la orden del día, y hay una clara pretensión (que sea consciente o bien inconsciente lo ignoro) de sostener un equilibrio entre los costos y la debilidad del sistema de tal manera que el patrón frecuente acostumbra a ser rentabilizar el sistema al límite y por ende, asumiendo muchos inconvenientes que no son populares (a.k.a son vergonzantes) en el mundo. Decidir si es un acierto o bien una equivocación a mí me da la sensación de que es considerablemente más bien difícil de lo que semeja, por el hecho de que si bien seguro que todos tenemos en psique proyectos que han sido un desastre, la verdad es que esas empresas marchan y ganan mucho dinero con esos sistemas tan débiles. Si les afecta, no lo semeja mucho.

esas empresas marchan y ganan mucho dinero con esos sistemas tan débiles

Por otra parte, asimismo hemos comentado que si bien un sistema no se modifique (no solo el codebase, me refiero a todo el sistema, incluyendo hardware, personal, etc.), la debilidad aumenta, si bien en tal caso, no se padece (manifiesta) dicha debilidad. Un caso podrían ser los juegos para videoconsolas, la enorme mayoría de los juegos tienen una debilidad latente bastante elevada (no tan grande como cabría aguardar por el hecho de que acostumbran a ser cajas negras, compárese dicha debilidad con aquellos que requieren un servidor para marchar…) mas el mecanismo de la emulación, deja congelar ese estado y la debilidad de todos y cada uno de los juegos emulados pasa a ser la que tenga el emulador.

Por lo tanto, que la debilidad exista en mayor o bien en menor medida no semeja ser tan relevante como que tenga un efecto real sobre nuestros objetivos. ¿No estaría bien poder determinar o bien regular exactamente en qué medida me va a afectar la debilidad de mi sistema?.

¿Qué hace débil un sistema?

Que sepa, absolutamente nadie lo sabe, o sea, no hay duda de que procede de infinidad de factores interrelacionados y trivialmente podríamos contar un sinnúmero de ellos, asimismo podemos contar cuestiones que nos semejan obvias (muchas de las que son extensamente discutidas, tan obvias no van a ser…), mas no hay un modelo matemático (sí ciertas métricas) que describa la evolución de la debilidad de un sistema y por ende que nos deje hacer predicciones, como se hace con el tiempo meteorológico, y actuar adelantadamente y/o de forma inteligente (precautoria).

De todas y cada una formas, podemos contar ciertos muy muy generales que abarcan otros muchos particulares:

fallos de software: esencialmente corner cases cruzados entre múltiples piezas de software que a posteriori son bien difíciles de identificar o bien, si bien son identificados, son bien difíciles de aplicar una solución global (por las interactúes producidas).
fallos en la arquitectura: esencialmente incongruencias en el/los modelo/s usados a lo largo del tiempo, generalmente introducidos por puro desconocimiento (ej. meditar que el usuario conoce las correspondencias de su negocio) o de forma consciente por imposibilidad de delimitar un modelo mejor, esto tiene (cuando menos) 2 causas no excluyentes, la carencia de recursos y/o la impredictibilidad (que no es precisamente desconocimiento).
fallos en el proceso: acá estarían todas y cada una de las técnicas abarcadas por el término buenas prácticas: clean code, documentación, patrones, testing, …
fallos de hardware: el software requiere un hardware para marchar (un emulador al final corre en un hardware) y no siempre y en toda circunstancia es simple imitar todo el contexto que requiere el software (por poner un ejemplo, ya hemos equiparado la debilidad de los juegos caja negra y aquellos que requieren un servidor para marchar).
fallos de personal: no solo de aquellas implicadas de manera directa en el sistema, incluso cuando la caja negra que describe nuestro software no padezca ningún género de modificación, la debilidad puede proceder del empleo que terceras personas hacen de él (en el boom de las .com [en España ya en este milenio] se percibió meridianamente, puesto que las webs viejas aceptaban un navegante friki mas poco a poco más navegantes normales accedían a la red requiriendo un replanteamiento de exactamente las mismas, todo ello derivó en libros como No me hagas meditar de Steve Krug).

Fragilidad del software y la entropía

Si estás al tanto de la segunda ley de la termodinámica, te habrás fijado que la evolución de un sistema software y la evolución de su debilidad tiene mucho que ver con la entropía de un sistema. Lehman señala que cuando se altera un software, su dificultad siempre y en toda circunstancia medra, mas (atrevido de mi) no estoy conforme puesto que nuestro sistema software no está cerrado y de exactamente la misma manera que nuestra entropía mengua con nuestro ciclo vital (comer y …; véase El camino a la realidad de Roger Penrose) podemos reducir la entropía de nuestro software a costa de acrecentar (por servirnos de un ejemplo) la nuestra.

Una demostración (a la fuerza informal) es que partiendo de un código vacío, podemos recorrer el ínfinito grafo de ediciones que podemos hacer sobre exactamente el mismo (por poner un ejemplo, v, vo, voi, void voidm, voidma, voidm, void, void , void m, void ma, void mai, void main, …) y en consecuencia es evidente que podemos movernos a voluntad por todo el grafo, donde cada entre los nodos corresponde a un estado de nuestro codebase (unos compilarán y otros no, unos van a tener más debilidad y otros menos, etc.). Afirmemos esencialmente que podemos reducir (¡o bien acrecentar!) la dificultad (debilidad y entropía) de nuestro software tirándola por el WC…

Este resultado era obvio, cuanto más recursos dediquemos, más probable va a ser (¡que no seguro!) que la debilidad de nuestro sistema se reduzca (moviéndonos por el grafo de estados de nuestro código), la cuestión es ¿cuales son los recursos mínimos precisos y de qué manera emplearlos a fin de que la debilidad de mis sistemas estén dentro de determinado margen?.

¿Cuáles son los recursos mínimos precisos y de qué forma emplearlos a fin de que la debilidad de mis sistemas estén dentro de determinado margen?

¿De qué forma disminuir al mínimo la debilidad de mi sistema?

Yo no lo se. La contestación simple es contar términos como clean, TDD, KISS, patrones, microservicios, … mas son solo técnicas, manifiestos, guías, … basados en la experiencia y que pueden o bien no encajar con nuestro contexto particular. Evidentemente emplear buenas prácticas semeja conveniente, mas no se debe olvidar que una buena práctica mal utilizada se transforma de forma rápida en una pésima práctica y, además de esto, ya hemos visto que dichas prácticas son solo una parte, no hace mucho Google se preguntaba porqué ciertos equipos de trabajo marchan y otros no (otro factor que tiene carices de afectar a la debilidad del producto).

Una buena práctica mal utilizada se transforma de forma rápida en una pésima práctica

Semeja entonces que hay algo sobre esas prácticas que debería poder hacerse de las que veo 2 sobre otras (que va a haber, que ignoro y que puede sean más relevantes): la experiencia y los pies en el suelo de quien aplica las soluciones, puesto que es dicha experiencia la que sabe elegir las técnicas (ej. herramientas, normativa, arquitectura, …) más convenientes para el caso (y esto es una cosa que no puede transmitirse de forma fácil de unas personas a otras; los términos enumerados previamente apuntan a ello) y algo que sí creo firmemente que asistiría substancialmente a contener la debilidad de nuestros sistemas son los estándares (pues definen autopistas sobre las que no hay margen de elección y pueden aprenderse fácilmente) que a absolutamente nadie semeja importarles demasiado o bien quizá absolutamente nadie logra acotar buenos estándares para nuestros inconvenientes mas, si lo piensas, son los estándares fijados hace décadas las unas partes de nuestros sistema que siempre y en todo momento marchan y de las que ni tan siquiera nos fijamos (por asumidas) cuando ponemos los dedos en nuestros teclados.

Asimismo te invitamos a

¿Qué es lo más terrible que has debido hacer programando?: El interrogante de la semana

¿Qué buenas prácticas de programación aconsejarías para sostener un código limpio?: el interrogante de la semana

Hey! Tablet: análisis de un dispositivo con una segunda pantalla led que te deja comunicarte con tu ambiente