Neurótico: (que padece una) enfermedad funcional del sistema nervioso caracterizada principalmente por inestabilidad emocional. https://dle.rae.es/neurosis

Los sistemas no presentan emociones (aún). Sin embargo, algunos sí presentan rasgos de complejidad y verbosidad exacerbada, como si estuvieran hiperexitados, nerviosos, cuyos momentos de euforia se demuestra en los picos de memoria y tiempos de espera agotados, y los de depresión en sus fallos. En efecto, “parecería” que tienen cierto estado anímico que se manifiesta en función de los “estímulos” que reciben (las solicitudes del usuario y otros actores externos).

Y ya imaginarás quién debe hacer las veces de terapeuta: el programador que, en su afán de corregir este comportamiento errático, debe intentar primero comprender la raíz del problema, para luego elaborar una estrategia de resolución. Un proceso de prueba y error en el que debemos hallar la forma de modificar esa conducta no deseada, dañina, sin causar efectos colaterales en otros aspectos del comportamiento del mismo. En algunos casos basta sólo una palabra para reponer el estado anímico de nuestro paciente; en otros, debemos plantear un cambio conductual profundo, quirúrgicamente.

Intentamos simplificar esta visión que tiene el sistema. Intentamos que sea más eficaz, más resiliente. Que sea un ciudadano modelo.

Debo decirlo: el origen de esta realidad es la vertiginosidad del negocio. La presión por adaptarse, por rendir más, por responder a la demanda, de la misma forma que ocurre con nosotros.

No olvidemos que a fin de cuentas (por ahora) somos los humanos los que escribimos ese código. Y plasmamos en el mismo, quizá sin darnos cuenta, nuestra falta de conocimiento, nuestro sentir, nuestras ansias y demás sensaciones. Y ese escenario de “máximo rendimiento” no es solamente personal sino colectivo; esto es, que se propaga a todo el equipo, a todo el departamento, y en los casos más extremos a toda la organización.

Y, aunque a veces dura, esta realidad no es negativa. Simplemente “es”. Es necesaria, es deseable, es… inevitable. Es el negocio intentando hacerse lugar para crecer. Y crecer duele, pero es parte del proceso, natural, esperable.

Toda esta analogía es para usted, joven desarrollador, que a veces no comprende por qué a veces el código no es “tan perfecto como te gustaría” y “por qué “nadie se quiere ocupar de la deuda técnica”. No es que nadie quiera; es que a veces simplemente no hay tiempo para hacerlo. De la misma forma que a veces uno posterga ese tiempo libre para hacer lo que quiere, o lo que necesita, para liberar presión, entonces uno ocupa los pocos ratos libres que tiene al mes, o al año, para organizar sus asuntos personales.

Es bello tener tiempo para lograr un código perfecto y libre de errores. Pero en la realidad, es difícil hacerse de ese tiempo, porque hay otras prioridades. Ante esto, existen tres posturas:

1. Ignorarlo;
2. Dejar de lado los requerimientos del negocio para ocuparse de la deuda;
3. Dar lo mejor de uno mientras atiende una tarea, e intentar mejorar la base de código en el proceso.

Sí, es una situación “ricitos de oro” (Goldilocks, para que los angloparlantes también comprendan la referencia). Las primeras dos opciones son “incómodas”, lo cual en la práctica se traduce como “no rentable” o “inviable”. Esto deja a la tercera opción como la más adecuada. Sin embargo, aceptarla implica compromiso pleno, responsabilidad, y saber reconocer cuándo decir “basta”. Es decir, “seniority”.

En la vida real, la pulsión por mejorar algo puede implicar demoras en la entrega, trabajar horas extras, y correr el riesgo de concluir en una solución peor que la original. Por ello, debemos tener certeza sobre qué queremos hacer, y criterio para determinar si emprender ese camino es viable o no en un momento dado.

• Refactor
• Codigo