El código de calidad es caro

2

Hace ya un par de años un compañero, a cargo de una Software Factory me dijo una frase que se me quedó grabada:

Programar bien, es caro

Joseba Pérez

A priori esta frase es simple, y parece obvia, pero escondía detrás la experiencia de empezar a programar bien. Y no digo que antes esa Software Factory programase mal, sino que no tenía el foco puesto en el arte de programar bien. El código se generaba para cumplir con todos los requisitos del cliente, y esa era la métrica principal. Pero de repente comenzó una tendencia interna a intentar conseguir un código limpio, un testeo con una cobertura suficiente, una arquitectura con sentido y un enfoque en la explotación. Eso derivó en que el código era más caro de producir. Una software factory no tiene que lidiar con el legacy que genera, eso es trabajo del cliente. Así que la software factory tomó la (acertada) decisión de crear un producto más caro y de mayor calidad, aunque eso a primera vista pareciese hacerles menos competitivos.

Ahora yo estoy de responsable de un área de desarrollo en java. Y me gusta decir que estamos programando bien. Arrancamos hace un año el proyecto Fénix, que básicamente consiste en redefinir completamente la arquitectura de desarrollo. Pasamos de grandes aplicaciones y grandes librerías, a microservicios. De framework propietario a framework RAD, en concreto Spring boot. Y lo más importante de todo, con un enfoque a la calidad del código.

El código de calidad

¿Qué entendemos por calidad del software? Si nos vamos a la Wikipedia, nos encontraremos con que no hay una definición para la calidad, sino que hay tantas como gurús. Y no hablemos de medidas de la calidad. Nos podemos perder en ese mundo.

Al final la calidad de un código se puede ver, simplificando mucho y aplicando el modelo CISQ, como el conjunto de:

  • Fiabilidad: Probabilidad de Errores
  • Eficiencia: El consumo de recursos
  • Seguridad: La probabilidad de ataque
  • Mantenibilidad: El coste de mantenimiento futuro, la facilidad de cambios, la barrera de entrada a nuevos programadores

Así cuando hablamos de un código de calidad, hablamos de que sea fiable, eficiente, seguro y fácil de mantener. ¡Ahí queda eso!

Cómo hacer código de calidad

¿Y cómo conseguimos hacer un código de calidad? Pues hay dos maneras, desde mi humilde punto de vista:

  • Personas: Teniendo a programadores excelentes en el equipo.
  • Procesos: Forzando unas determinadas prácticas.

La primera parte, la de las personas, desde mi experiencia, es cierto como la vida misma. Hay gente que tiene ordenada la cabeza de determinada manera que genera de forma natural un código limpio, que cometen menos fallos y que continuamente están vigilando la seguridad y la eficiencia de su código. Tengo muchos ejemplos de esta gente en mi equipo. Pero por ilustrar con la experiencia os cuento uno:

Tenemos un sistema que responde a millones de peticiones diarias, y cada una de ellas requiere mucha lógica de negocio y muy compleja. El programador lider de ese proyecto es de esas personas que cuando te da por mirar su código parece como un libro abierto: limpio y claro. Que cada dos por tres está mirando la eficiencia de su código y mejorándolo. Puedes ver como cada mes el numero de peticiones a procesar aumenta a un ritmo exponencial, y como el número de servidores en paralelo crece linealmente. Cuando hay que hacer una mejora, no ves que haya un legacy que aumente el coste peligrosamente. El sistema se vuelve cada vez más complejo, pero el coste de añadir funcionalidades, parece mantenerse constante. Resumiendo, ves los indicadores de un código de calidad. Y cuando se desarrolló no teníamos procedimientos o cultura de calidad global, ese resultado es puramente por tener un equipo de calidad. En Idiso, donde trabajo ahora, tenemos la suerte de tener muchos de estos.

Pero por muy bueno que sea tu proceso de selección no vas a tener un equipo que sea el 100% de este tipo. Siempre tendrás Juniors o gente con otra cultura u orientación. A esta parte del equipo no le saldrá esta calidad de forma natural. Cumplirán por supuesto con su trabajo, realizando el desarrollo que se les pide, pero el nivel de calidad, expresado como en el capítulo anterior, no será el mismo.

La segunda manera de tener calidad es aplicando buenas prácticas como por ejemplo:

  • Forzar QA
  • Exigir una cobertura de test unitario
  • Implantar guías de estilo
  • Forzar prácticas en el desarrollo (tamaño de clases o procedimientos por ejemplo)
  • Implantar un control y monitorización sobre la calidad del código (como SONAR)
  • Forzar la revisión de iguales
  • TDD
  • Requisitos de monitorización y explotación
  • XP Programming

Son solo algunas de las medidas que se pueden tener para forzar la calidad.

Por último indicar que los procesos y cultura de empresa que tengas pueden llegar a forzar a esas personas con calidad intrínseca a perderla. Si la organización exige entregas lo antes posible y no entienden retrasos por pruebas, pueden llegar a contaminar a esas personas y hacerles perder esa cultura.

Por lo tanto, aunque tu equipo sea 100% de calidad, siempre necesitarás unos procesos y un apoyo para mantener esa calidad.

El coste de la calidad

Volvamos a la primera frase: “La calidad es cara“. Y eso se aplica a las dos formas de conseguir calidad. Por un lado las personas que programan de forma natural con calidad, suelen requerir salarios más altos (y los merecen). Por otro las prácticas en los procesos, implican tardar más tiempo (y más coste). Incluso las personas que trabajan de forma ordenada saben que les lleva más tiempo trabajar así. Probablemente podrían tardar menos en hacer su trabajo, pero su forma de ser y su profesionalidad les impide hacerlo más rápido. ¿Cómo podemos medir ese coste?

En SimpleProgrammer definen varias variables para medir este coste:

  • Overhead: El sobrecoste de aplicar los procedimientos para mejorar la calidad
  • Quality Savings: El ahorro, durante el ciclo de vida del software que generará esa calidad.

Cuando hablo que en mi equipo empezamos a enfocarnos en la calidad, hablo de empezar a institucionalizar esas medidas de procedimiento. Y esto ha aumentado el coste de los proyectos. Sólo en testeo solemos llevarnos un 30% de overhead. Es decir, un proyecto de 3 semanas en desarrollo, con testeo de regresión y unitario a los niveles que exigimos ahora, se nos va a las 4 semanas.

Pero luego hay muchos otros costes:

  • Un equipo de QA invirtiendo en crear nuevas herramientas, como un SONAR o nuevos criterios para medir la calidad.
  • Un equipo de arquitectura invirtiendo en crear piezas reutilizables, documentación o formación en hacer código de calidad.
  • Un análisis de los proyectos orientado a conseguir piezas reutilizables y duraderas.
  • Enfoque a la seguridad, aplicando nuevas medidas.
  • Enfoque a la operación y al mantenimiento, creando utilidades orientadas a mantener las aplicaciones en producción.

De los proyectos de este año, el overhead nos está superando el 50%. Esto quiere decir, que nos estamos gastando un tercio del presupuesto en hacer cosas mejores, en vez de hacer cosas nuevas. Y en algún proyecto, lo estamos midiendo cerca del 100% (lo cual mirando por Internet sobre valores típicos, no es tan exagerado).

Cómo dicen en SimpleProgrammer, el comienzo es la parte más dura, así que esperamos que en años futuros, este overhead se reduzca, pero ahora mismo estamos en estos valores. Los proveedores que desarrollan software para nosotros nunca se habían enfrentado a estos niveles de calidad.

El retorno de la calidad

Bueno, esperamos grandes retornos de esta inversión que hacemos. Estamos invirtiendo muchos recursos en conseguir que todos generen código de calidad. Y queremos ver los frutos. Es lo que en el capítulo anterior llamaba Quality Savings, pero no sólo son los Quality Savings, también hay otras ventajas.

Los primeras ventajas ya los estamos vislumbrando:

  • A la gente le gusta hacer cosas de calidad. Le gusta estar orgulloso de su trabajo. Es un punto motivador en el equipo.
  • Los primeros proyectos no fallan. Exacto, esa es la clave. Tenemos pocos proyectos on-line con la nueva arquitectura, y llevan poco tiempo, pero estamos viendo que no fallan. Y hay algunos procesando muchas transacciones. Eso aumenta la confianza de la organización hacia el equipo.
  • Los primeros proyectos son como un libro abierto: Tenemos métricas on-line al momento de todo lo que hacen. Por lo que el mantenimiento y auditoria se hace más fácil. Con lo que no sólo se reduce el coste de operación y mantenimiento, sino que los tiempos de resolución son mejores, con lo que el valor del servicio proporcionado aumenta.

Es pronto todavía para hablar de los Quality Savings, pero esperamos que supere el Overhead y que los programadores inviertan más tiempo en crear y menos en mantener. La empresa gana más, y ellos se lo pasan mejor. Pero todavía es una incógnita. Sólo el tiempo nos dará la respuesta.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información.
Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector.
Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo.
Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

2 comments

  1. Carlos Acervo 22 julio, 2017 at 14:49 Responder

    Muy buena la disertasión. Y muy bonita la aventura de comenzar a aplicar las prácticas de calidad y nueva tecnología. Gracias por compartir su experiencia. Pero tengo una pregunta, a ver si usted me la puede resolver. ¿Como hace para que la dirección de su empresa acepte gastar más por tener más calidad?

    • Jose M. Huerta 22 julio, 2017 at 16:19 Responder

      Gracias Carlos. Es cuestión de plantear el caso de negocio en términos que la dirección pueda entender. No se trata de explicar si usaremos tal o cual técnica, sino de hablar del sobrecoste esperado y del retorno. Estoy hablando de hacer el mismo cálculo que planteo en este ejercicio. Sin el apoyo de dirección, este camino es muy cuesta arriba.

Post a new comment