La deuda técnica

La deuda técnica es un tema importante a considerar en el desarrollo de software. Se refiere a la acumulación de tareas pendientes, como la documentación, el mantenimiento, el refactorizado y la eliminación de código obsoleto. A medida que la deuda técnica aumenta, se vuelve cada vez más difícil y costoso mantener y mejorar el software.

Robot arreglando código

En mi experiencia, hay varias razones por las que la deuda técnica puede acumularse. Una de las principales es la falta de tiempo para dedicar a tareas no relacionadas con el desarrollo de nuevas funcionalidades. A menudo, se priorizan las tareas que producen resultados visibles a corto plazo en lugar de las que tienen un impacto a largo plazo.

Otra razón es la falta de disciplina en el desarrollo de software. A veces, los desarrolladores se sienten presionados por plazos ajustados y optan por escribir código rápido y sucio en lugar de tomarse el tiempo para refactorizar y documentar adecuadamente.

La solución para reducir la deuda técnica es simple pero no es fácil. Es necesario dedicar tiempo y recursos para abordar las tareas pendientes. Esto puede incluir dedicar tiempo cada semana para el mantenimiento y la documentación, o incluso asignar un equipo específico para abordar la deuda técnica.

Además, es importante fomentar una cultura de disciplina y responsabilidad en el equipo de desarrollo. Esto puede incluir establecer estándares de calidad y proporcionar retroalimentación continua sobre el cumplimiento de estos estándares.

En resumen, la deuda técnica es un problema común en el desarrollo de software, pero puede ser manejado si se toman medidas proactivas para abordarlo. Dedicar tiempo y recursos, y fomentar una cultura de disciplina y responsabilidad, son fundamentales para reducir la deuda técnica y mejorar la calidad del software.

Errores de gestión… Las empresas de becarios

Uno no deja nunca de aprender, sea de informática o sea de gestión, en este caso me toca hablar de una tendencia que se afianza día a día en las empresas de informática y de la que he tenido un ejemplo flagrante hace muy poco. La lección de hoy, queridos lectores, es que, nunca, nunca, nunca, hay que dejar que tu empresa sea solo un conjunto de becarios.

¿Son malos los becarios? Claro que no, seguro que en poco tiempo se convierten en unos excelentes profesionales. Con la guía adecuada, y aprendiendo de los profesionales de verdad, todos aprendemos y nos convertimos en profesionales, con poca experiencia, pero profesionales. Entonces, ¿porqué me quejo? Veamos el ejemplo.

Una startup de la que prefiero no acordarme, comenzó su andadura en un nicho de mercado en el que partía con ventaja. Sus socios eran lo mejor de lo mejor en sus áreas de experiencia. Unos provenientes de la parte académica, pero con experiencia en proyectos de investigación, otros con experiencia en el desarrollo de software a nivel profesional y un gestor que creía que sabía de todo que encontró el dinero y los inversores necesarios.

Como toda startup su obligación es focalizarse en su proyecto principal y quemar dinero hasta que consigue sacar al mercado su idea o se queda sin dinero. No obstante, por errores que no vienen al caso, la idea principal se marchitó y se lanzaron a intentar crear productos en mercados cada vez más abarrotados, donde no contaban con las ventajas anteriores y con el dinero ya mermado. En esas los socios más interesantes y menos comprometidos fueron abandonando el barco, o bien se vieron obligados a abandonar al no tener expectativas de obtener un salario digno (digo digno, no a la altura de sus méritos, que eso siempre es mucho más, pero, oye, estamos en una startup). Estas personas son reemplazadas por becarios de manera que, al final, solo queda un socio con conocimiento y experiencia y el resto que se limita a aprender lo mejor que puede intentando no romper demasiado.

Y el error principal viene cuando el gestor, en su afán por prolongar una agonía innecesaria, decide sustituir a este socio «excesivamente caro» por otras personas de un nivel muy inferior, sin capacidad de trabajo ni compromiso con la empresa pero obedientes y baratitos… El resultado, el de siempre, una mierda.

¿Puede una empresa sin conocimiento práctico, sin experiencia, sin foco y sin socios comprometidos trabajando en la misma triunfar? ¿puede acaso sobrevivir? A los ojos de quien solo mira números y no valora el trabajo real de ninguna manera es la consecuencia evidente, pongo dos por el precio de uno y gano en el cambio… ¿Ganar qué? Duplicas el numero de problemas, dilapidas el poco conocimiento que tenías y llevas a cero la confianza de los inversores en una empresa que se puede montar con cualquiera que pase por allí y que no premia ni valora experiencia ni conocimiento… En fin…

La épica del informático

programmingHoy toca una entrada para alabar la tarea de nuestros trabajadores del conocimiento (eufemismo clase Dios) que son, como no, ninguneados e ignorados silenciosamente por el público en general y por sus jefes en particular. Pero esperad, antes de eso, un «mea culpa»… ¿Porqué los profesionales de la informática son tan despreciados en esta, una sociedad construida en base a su esfuerzo? Os diré mi opinión… Porque acostumbramos mal a nuestros clientes. Nos piden lo imposible y se lo damos, nos quejamos, nos revolvemos contra la ignoracia atrevida del que nos pide la luna pero finalmente cedemos y eso es lo que nos conduce inexorablemente a las mazmorras de nuestro propio talento.

Si alguien pide un presupuesto a un fontanero para que le ponga un grifo debajo de la cama (por estúpido que eso sea) y consigue un profesional que no se descojone de su ocurrencia y le de el presupuesto lo más normal es que consiga su grifo y nada más. Imaginemos la conversación:

  • Cliente: ¿Qué es esto que me has puesto aquí?
  • Fontanero: un grifo
  • Cliente: pero está debajo de la cama, ¿cómo voy a poder usarlo así?
  • Fontanero: es lo que pidió
  • Cliente: si, claro, pero es de sentido común que un grifo debajo de la cama debe tener algo que permita que se use desde encima de la cama
  • Fontanero: eso no es mi problema
  • Cliente: venga, no me vengas con esas, un grifo que no se puede usar no te lo voy a pagar.
  • Fontanero: es lo que has pedido y es lo que tienes que pagar
  • Cliente: ya, pero al menos harás que se pueda usar desde la cama
  • Fontanero: solo tienes que bajar de la cama y amorrate al caño
  • Cliente: eso no es práctico
  • Fontanero: ya ¿y?
  • Cliente: venga, me haces un apaño para que pueda usarlo desde la cama y luego te contrato la pila del baño
  • Fontanero: ni de coña, aquí tiene la factura.
  • Cliente: bueno, vuelve dentro de un mes y te pago junto con el resto de..
  • Fontanero: ahora
  • Cliente: esto…
  • Fontanero: ¿Pagas o me llevo el grifo y se te inunda la casa?

Bueno, algo así… Los clientes suelen ser más razonables con los fontaneros que con los informáticos, porque, total, seguro que a los informáticos les gusta hacer mal su trabajo y no ponen todas las cosas que tienen que poner porque son vagos.

¡Pues no!

Los informáticos, y los programadores principalmente, son héroes. Gente que consigue lo imposible, que cumple con requisitos inverosímiles, que estira el tiempo disponible hasta lo absurdo para conseguir terminar algo que, probablemente, luego sea mal juzgado por algún ignorante en la materia. Los programadores más experimentados crean obras de arte en unas líneas de código que, aunque podrían ser admiradas en museos donde otros programadores no puedan más que deshacerse en halagos, al final son ejecutados una vez por alguien que no está preparado ni para programar una lavadora y obtienen un comentario estúpido sobre el número de clicks que hay que hacer… Estos héroes anónimos mueven nuestro mundo, allí donde mires hay un programa que escribió alguien, que hace más sencilla tu vida, o que te permite hacer cosas impensables hace solo unos años. Estos héroes sin nombre que, por lo menos en España, están mal pagados, mal vistos (como si picar código al azar en un editor fuese programar), mal dirigidos por gente sin criterio y sin empatía. Formando parte de hojas excel que los mide en kilos de carne y los vende y los compra a otros patanes con ínfulas que creen que hacer informática es un simple problema de coste.

Por todo ello, amigo gerente, si alguna vez un programador te intenta explicar lo difícil que es conseguir algo, entiéndelo como un cumplido que te hace intentando dejar que veas una porción pequeña de su complejo mundo interior. Intenta comprender que no te está intentando dar una excusa, sino describiéndote el peligroso campo de batalla en el que va a meterse en tu nombre y dar hasta su última gota de sudor y sangre para acabar con el enemigo y conseguir esa funcionalidad que tu describes en una frase pero que eres completamente incapaz de explicar en sus detalles (o, simplemente, no quieres hacerlo por pereza).

Día a día, proeza a proeza, sin parar, sin esperar recompensa, sin aparecer en los libros de historia (ni siquiera viendo reconocida su propiedad intelectual muchas veces), el programador anónimo sigue siendo el motor de esta sociedad y, desde aquí mi más sincero agradecimiento a todos ellos. Y, por favor, dejad de tratar a los gerentes como niños, que ellos no quieran escuchar los problemas no significa que estos no estén ahí y que merezcan verlos con sus ojos… Igual así despiertan y os empiezan a tratar como lo que sois, los nuevos magos de la tecnología moderna.

Lecciones informáticas: La resistencia al cambio

Hoy en día están apareciendo un montón de noticias sobre la posibilidad de reemplazar obreros por robots y los cambios económicos que esa situación desencadenaría. En efecto el temor a ser reemplazado por máquinas no es algo nuevo y viene provocado, en mayor o menor medida por una resistencia al cambio que es, en el caso de la tecnología, un freno importante a la adopción de nuevas maneras de trabajo.

301111_1462_1No pienso soltar aquí una lección sobre la resistencia al cambio, pero si que quiero dejar algunas notas sobre las resistencias más obvias que he encontrado en mi carrera y algunas recetas comunes para lidiar con ella. Como siempre, lo veremos con ejemplos reales.

Cada vez que se diseña un nuevo sistema empresarial hay que tener en cuenta no solo al cliente (que es quien paga), sino al usuario final y a aquel que va a trabajar con el sistema de alguna manera (que no tienen porqué coincidir). Las actitudes y motivaciones de cada uno de estos actores suele ser diferente e, incluso, en muchos de los casos divergente. Cuando me han encargado un sistema siempre he intentado tener en cuenta a todos los usuarios, pero hay veces que los conflictos han de solucionarse en la organización y no tiene nada que ver con el sistema. Los problemas más habituales suelen ser:

  • Falta de involucración de la dirección. A pesar de ser quien financie el sistema nuevo, hay veces que los mismos directivos encargan los sistemas para «modernizarse» sin haber pensado en serio que el sistema cambiaría la forma de trabajar de sus empleados. Si se construye el sistema siguiendo las directrices de la dirección lo más probable es que los usuarios terminen renegando del sistema y eviten por todos los medios que este pase a producción.
  • Falta de motivación entre los usuarios. Si algo funciona no lo cambies… dice la máxima de los ingenieros, y eso es así siempre que los cambios no aporten valor de verdad. Los usuarios suelen estar acostumbrados a hacer las cosas de una manera y si no somos capaces de explicarles las ventajas que traerá a su trabajo el nuevo sistema (o si estas no existen), los usuarios estarán más motivados a ignorar el nuevo sistema que a usarlo de verdad. Si el sistema no se prueba y consensúa con los usuarios es muy dificil que su uso sea voluntario.
  • Falta de comunicación entre los distintos actores. Por mucho que seamos unos desarrolladores impresionantes y seamos capaces de realizar proezas técnicas, si no hacen lo que deben o en la manera en la que puede ayudar a los usuarios a realizar su trabajo estaremos construyendo en el vacío. Solo se puede construir algo útil si nos comunicamos con todos los afectados y ellos entre sí. Consecuencia de esta falta de comunicación puede ser la falta de entendimiento sobre los objetivos del proyecto. Lo que a unos les puede parecer un sistema fundamental para el funcionamiento futuro de la empresa para otros puede verse como un gasto inutil de dinero que no va a ser utilizado.
  • Exceso de «mano izquierda». Si alguien os dice alguna vez que es capaz de contentar a todo el mundo, simplemente te está mintiendo. Con los acuerdos (si son buenos) todo el mundo queda insatisfecho en algún aspecto, pero ha conseguido que los aspectos importantes sean tenidos en cuenta. Si algún gestor intenta tener a todo el mundo contento a base de mano izquierda, sin ceder ni exigir lo suficiente, la negociación y la implantación del sistema estarán abocados al fracaso.

¿Cómo se debería realizar una implantación exitosa de un sistema en una organización?

En primer lugar habría que recopilar todas las opiniones de todos los afectados para ver si la idea es compartida, si es una simple imposición o si nos encontramos con oposiciones frontales. En caso de que la idea no sea compartida hay que conseguir, ya desde el momento de los requisitos, involucrar a cuantos más usuarios mejor para intentar averiguar en que puntos el nuevo sistema les va a hacer la vida más sencilla… Si no conseguimos esto, bueno, estaremos ante un sistema impuesto y, probablemente, mal orientado desde la dirección… Si, podemos hacerlo, pero ya sabemos que no será adoptado sin más.

Antes de terminar el sistema se necesita que los usuarios finales (o los principales) vean resultados y hagan comentarios de mejoras que poder introducir. La mayor parte de las veces serán mejoras interesantes y, si la resistencia es fuerte, al menos mostraremos que se les tiene en cuenta. Llegados a este punto puede pasar que la cooperación no exista. Pueden pensar que no es su trabajo andar con pruebas de sistemas sin terminar o que no quieran en absoluto oir hablar del sistema. Este es un caso de manual en el que se requiere que la dirección se involucre y vuelva a explicar qué se espera del sistema y porqué se les está teniendo en cuenta en su construcción. Fallar en esta comunicación nos da muchos puntos para que lo que se termine produciendo sea tirado a la basura.

Finalmente, cuando el producto está terminado, antes de pasar a producción definitivamente habría que mantener un «paralelo» entre las formas de trabajar antiguas y nuevas de manera que se hagan patentes las ventajas. Si no hay ventajas es que algo hemos hecho mal.

Si el sistema se impone por parte de la dirección veremos que los problemas que nos surgen serán algunos de estos:

  • Quejas constantes, intentando demostrar que el sistema está mal construido y atacando de cualquier manera la posibilidad de su paso definitivo a producción.
  • Lentitud de aprendizaje. Aunque el sistema sea sencillo e intuitivo, si se da la impresión de que es difícil de utilizar se están poniendo piedras al despliegue definitivo y puede que se consiga retrasar el mismo exigiendo más formación.
  • Ignorar el sistema. Aún más doloroso que las quejas constantes es la actitud de los usuarios que cuando les salta un error deciden, por su cuenta y riesgo, volver a la forma antigua de trabajar diciendo «esto no funciona» y tirando por la borda cualquier posibilidad de arreglar el problema, informar del uso correcto o corregir el defecto.

Todavía recuerdo el día en el que entregamos un gran sistema web para muchos miles de usuarios y el empleado encargado de mantenerlo a partir de ese día (que era el responsable del sistema anterior) decidió negarse a responsabilizarse del nuevo sistema porque nadie le había preguntado. Como el proyecto era para una administración pública no había manera humana de convencer a este funcionario ni de hacerle entrar en razón, así que se tuvo que contratar a otra persona para que hiciese su trabajo, con el coste añadido que esto suponía.

También me escuece aún el recuerdo del paso a producción de un sistema que tardamos seis meses en recopilar los requisitos manteniendo reuniones semanales con todos los afectados y, tras pasar a producción el sistema, nos llamaron para decirnos… Muy bien, ya vemos que tipo de cosas hace el sistema, ahora os vamos a contar qué es lo que queremos que haga…… ¡¡¿¿??!!

Los errores SI se pagan

Tengo un jefe que dice que su empresa no paga errores y que las tareas dedicadas a depurar y corregir errores deben hacerse en el tiempo libre.

human-error-in-finance-640x324A mi, que no soy muy dado a cometer errores y que tampoco dispongo de mucho tiempo libre eso me parece simplemente una barbaridad, y no solo porque estemos hablando de ingeniería del software, sino porque estamos hablando, en general, de trabajo hecho por humanos. Es completamente imposible asegurar que el 100% de un trabajo realizado por un ser humano está exento de errores, enmiendas u omisiones. Decir que solo se paga por el trabajo «perfecto» es como decir que te están pagando solo una fracción del tiempo que dedicas. Y eso, simplemente, es explotación.

Según Frederik P. Brooks, Jr. El autor, entre otros, del conocidísimo libro «The mythical Man-month» y autoridad donde las haya en el campo de la ingeniería del sofware, el 50% del tiempo total de un proyecto software debe dedicarse a pruebas, depuración y corrección de errores. ¡Un 50%! más tiempo que el dedicado a programar o a cualquier actividad de gestión. ¿Eso significa que si se hubiese aplicado la política de «yo no pago errores» el software habría salido por la mitad de precio? No, significa que los errores en el software son inevitables y que el buen software no es el que se construye sin cometer errores sino el que se hace teniendo siempre presente que los errores están ahí y hay que corregirlos antes de sacar nada al mercado.

Escudarse en la excusa de que un programador experimentado es el que no comete errores, es una falacia completa. El programador experimentado es aquel que ya ha cometido más errores y, por tanto, tiende a no volver a cometerlos o, al menos, a reconocer los errores cuando los encuentra más rápidamente que otro programador que no ha tenido esa experiencia. Además, muchos «errores» no son más que malas interpretaciones de requisitos o malas integraciones de sistemas distintos que no se habrían podido evitar sin cambiar las políticas de comunicación de la empresa (¿alguien recuerda el pufo de las distintas unidades de medida en la Mars Climate?).

Por más controles que se pongan, por mejores herramientas que se utilicen, por más que estemos concentrados en lo que hacemos el 100%, es imposible evitar la introducción de errores en el código que se produce. Las tareas de pruebas y depuración son muy importantes y determinantes a la hora de medir la calidad del resultado final. Intentar no pagar por esas horas es como invitar a alguien a comer y decir que los entremeses y el postre lo tiene que pagar él. ¿Qué invitación es esa?

Espero que vosotros no os encontréis esta situación que, por otra parte, no debería darse entre gestores formados y experimentados en el campo de la ingeniería del software. Hora que trabajas, hora que se paga. Si eres malo en lo que haces te pagarán menos por cada hora y terminarás en la calle, pero si eres bueno, igualmente cometerás errores (y los corregirás) en horas pagadas acorde a tus habilidades. El resto son milongas.