Pages Menu
Categories Menu

Posted by on Feb 27, 2013 in General | 0 comments

La historia de Lucas, o como medir la calidad software arruinó su carrera

Preparando el curso de calidad de producto (no proceso) que tenemos el viernes 8 de marzo (toda la info aquí) he recordado el post sobre la historia de Lucas, ese post que tenía casi terminado hace semanas y al que hoy le ha llegado su momento…

Por aquellos tiempos, Lucas (pseudónimo, cualquier parecido con la realidad es pura coincidencia) ya tenía decidido dar un cambio de rumbo a su carrera profesional. Ya había hecho varias entrevistas y ya se había decidido por una nueva empresa.

El nuevo puesto parecía bastante prometedor: buen sueldo, cargo de responsabilidad, nuevo equipo, etc. Aunque, para ser sinceros, aquellos directivos con un toque a “Los Fratelli” que le habían contratado no le habían apasionado mucho, pero “a quién no le ha tocado algo así en este sector”.

Lo primero que le encomendaron fue que, ya que él parecía tener “conocimientos solidos” en desarrollo software, propusiera una metodología o modelo de procesos que pusiese solución al retraso de año y medio que ya llevaba el desarrollo estrella de la empresa.

Lucas, ducho ya en batallas similares, les propuso que, antes de proponer una metodología, proceso o certificación, lo que haría sería “hacerle un chequeo médico al enfermo y poder determinar las causas de sus males antes de recetar medicina”. Aquello sonó a chino en el comité de dirección, pero bien fuese por no preguntar de qué estaba hablando, o por probar cosas nuevas, accedieron al cambio de enfoque.

Dicho y hecho, Lucas se hizo con una versión de los fuentes de la aplicación, y empezó a sacar métricas de la misma. Lo tanto que le costó encontrar una última versión de los fuentes ya le indicaba los graves problemas que había en gestión de configuración. Pero aún así, en apenas un par de días tenía todos resultados que necesitaba.

La disparada “complejidad ciclomática” evidenció graves problemas de diseño, un mal diseño orientado a objetos, y mucho código espagueti. El exceso de código “copy paste” reforzó los anteriores problemas y empezó a dar forma a las causas por las cuales cualquier cambio en el software requería de tanto tiempo y tanta gente. La alta dependencia entre clases concretas había hecho imposible hacer pruebas unitarias en tiempos razonables, y de ahí la baja cobertura de pruebas unitarias que mostraban las métricas.

Dependencias cíclicas, clases padres que conocían a sus hijas, SQL embebido en lógica de negocio, decenas de estilos de codificación, exceso de comentarios en código, etc., fueron otros de los muchos datos extraídos, y que supo sintetizar perfectamente en un breve y ejecutivo cuadro de mando.

Cuando Lucas expuso su informe a la junta directiva no había lugar a dudas: la solución no pasaba por una metodología o modelo de procesos, era necesario una completa reestructuración de módulos críticos del software, si se quería cortar el sobre coste del desarrollo, y evitar que ciertas malas prácticas volvieran a repetirse. De haber controlado desde un principio la calidad del producto software, esto se hubiera podido evitar.

Lucas hasta incluso fue capaz de hacer una simulación económica de cuanto gasto habían supuesto las malas prácticas de calidad software, y como se justificaba económicamente haber contratado desde el principio gente con un mayor conocimiento en desarrollo.

Y ese modelo económico fue el último informe que Lucas hizo en aquella empresa.

Que sacase un informe de métricas cada dos semanas para ver si el desarrollo mejoraba o empeoraba no había gustado nada a los directores de los productos. Y ni el informe que periodicamente mostraba métricas cuantitativas de lo mal que estaban las cosas, ni el informe económico de gastos que pudieron haberse evitado habían gustado a su jefe.

Lucas siempre pensó que la mañana en la que le invitaron a dejar la empresa no sólo pesó que su manera de trabajar se “alejaba de la cultura” de la misa, si no también que sus informes dejaban datos numericos de que el trabajo no esta ni bien hecho ni bien dirigido.

Lo dicho, y si no quieres que te pase lo que a la ex-empresa de Lucas… pásate por el curso de calidad del producto que damos el viernes 8 en Madrid. Mientras te dejo algunos post sobre algunos de los temas que allí trataremos…

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

0 Comments

Trackbacks/Pingbacks

  1. Bitacoras.com - Información Bitacoras.com... Valora en Bitacoras.com: Preparando el curso de calidad de producto (no proceso) que tenemos el viernes 8…

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This