Qué es eso de deuda técnica… Más o menos, antes o después nos topamos con ese término tan cool… Deuda técnica. Todo el mundo conoce más o menos el concepto sobre el papel.

Deuda técnica: Deuda de trabajo que se adquiere al producir código pobre, incumpliendo prácticas aconsejadas para el desarrollo de software.

En principio está claro… está claro que sucede, pero no está tan claro cómo se llega hasta allí… hasta ese punto que se vuelve algo imposible de manejar.

Personalmente creo que es algo que se puede “oler”, aunque en un entorno grupal es más difícil de darse cuenta si no hay un grupo cohesionado e instrumentos que ofrezcan transparencia. En más de una ocasión tienes un pálpito, algo que no te acaba de encajar en el proyecto global… que el tiempo acaba mostrándote antes o después.

En un esfuerzo por luchar contra esa deuda técnica, se aplican varias prácticas y recetas para mantener limpio y ordenado el código… pero no nos engañemos… En un proceso creativo como el desarrollo de software, donde hay tantas disciplinas juntas y que unas dependen de otras… con fechas de entrega acechando, la deuda técnica es algo inevitable.

Entonces… ¿Qué hacemos?… Calma, lo único que se puede hacer es aceptar que va a existir ese factor y confiar el la experiencia de los que ya han estado ahí y nos han dejado recomendaciones en forma de buenas prácticas. La deuda técnica es algo que se puede gestionar. Es algo a incluir en el global.

Crear, dar un paso atrás y replantearse si estamos en el camino correcto.

¿Vale, y qué tiene que ver la deuda técnica con la teoría de las ventanas rotas?

La teoría de las ventanas rotas establece un patrón sobre un comportamiento grupal ante un ambiente descuidado que indica que nadie se encarga de mantenerlo. Si en una empresa se descuidan algunas normas éticas, el ambiente se deteriora. Una vez que se empiezan a desobedecer las normas que mantienen el orden en una comunidad, tanto el orden como la comunidad empiezan a deteriorarse, a menudo a una velocidad sorprendente.

Este tipo de comportamiento es una conducta, y es extrapolable a otros aspectos como el del trabajo en equipo, desarrollo de software…

Como es una conducta, está en manos del grupo mantener la calidad y las buenas prácticas en el desarrollo de software, pero también en los demás ámbitos que rodean a la tarea de desarrollar… Si en el área de sistemas, o en el de diseño no tienen ese sentimiento de pulcritud, entrará en confluencia con el resto de componentes del sistema y antes o después se degradará todo el proyecto.

Si no se gestionan esas “ventanas rotas” que son el código, la infraestructura, el diseño, y las formas de comunicarse, podemos sentir una sensación de “todo vale”, y cuanto más grande sea el proyecto y más gente esté involucrada, con mayor rapidez se degrada en entorno a nivel de código y soluciones.

Un código o un diseño pobre repercute en tiempo intentando “parchearlo”, el cual acaba en un rendimiento pobre, que se intenta compensar desde sistemas…. o el esquema de la base de datos acaba siendo caótico y los del área del BI buscan su propias soluciones creando tablas intermedias y consultas del tamaño de Godzilla intentando “fusionar” los diferentes criterios que se han ido generando a través del diseño.

Si al final no sólo es hacer código limpio… ¿Qué se puede hacer en global para tener controlado el problema?

Es necesario controlar el problema desde todos los frentes posibles. Además de código limpio y buenas prácticas, existe un entorno físico en el que se desarrolla la actividad de la empresa, las personas interactúan entre ellas e intercambian ideas. Creo que las buenas prácticas se pegan igual de bien que las malas. Es más un tema de motivación. Y… ¿ qué mejor motivación que te sientas parte del grupo en un ambiente abierto, ordenado y colaborativo?

Cada empresa, cada organización, requiere medidas adaptadas a su naturaleza. Aunque si que existen métodos que ayudan a mantener el rumbo y nos permite mejorar y evolucionar aprovechando estrategias y fórmulas de los que ya se han visto en situaciones parecidas.

Las que me llaman la atención y que por su extensión quedan fuera del ámbito de este post son:

Empresa

• Lean
• Kaizen
• Equipo
• Scrum y sus artificios como el planning poker

Programadores

• Programación en parejas
• Código limpio

Otros ámbitos más personales

• GTD

Somos seniors, hasta que cambia lo que conocemos, la tecnología, el software, el modelo del negocio… y entonces volvemos a aprender como juniors. Y sólo podemos llevarnos a ese nuevo lugar algo intangible, que si hemos cultivado bien, hará que todo sea más fácil.