archivo

Archivos diarios: diciembre 13, 2011

Si compras un vehículo o un electrodoméstico de una marca y te sale malo o si te enteras que le ha pasado a alguien próximo a ti, ¿a que lo más probable es que finalmente te decantes por otra marca?.

Para algo que es tan evidente en nuestro día a día parece que tengamos vendas en los ojos cuando estamos hablando de desarrollo de software.

Vale que desarrollar es muy complicado, que los proyectos se realizan en un marco de incertidumbre pero eso no se justifica una mala calidad prácticamente institucionalizada en los productos software.

Precisamente ese es uno de los principales problemas de nuestro sector, habernos acostumbrado a un umbral de calidad cada vez menor y no conseguir una regularidad en la ejecución de los proyectos (es complicado que todos salgan bien, pero por lo menos, se debería alcanzar un bagaje favorable o, al menos, intentarlo, ya que la mala calidad institucionalizada es consecuencia, entre otros muchos factores, de una orientación a la ejecución de los proyectos, es decir, acabarlos como sea, facturar como sea, dejando a un segundo lado, siendo generoso, la orientación a cumplir las expectativas del usuario y/o cliente).

¿Resultado? Que nuestra profesión esté estancada, que nuestro negocio, fuera del glamour de los Apple, Google, etc… no tenga el reconocimiento que se merece, esto lleva a sueldos no equiparables al esfuerzo y responsabilidad que tenemos y a que cada vez sea más complicado tener una cuenta de resultados sostenible.

Siempre en el peor momento y después toca correr para corregirlas. El problema es cuando no hay espacio para frenar y tras él solo queda el abismo.

No somos infalibles, de hecho no debemos serlo, salvo que el sistema sea tan crítico como para que de él dependan vidas humanas o se comprometa la viabilidad económica o de negocio de una organización. Pero una cosa es saber que cometeremos errores, aceptar un determinado umbral adecuado a las características del proyecto y su presupuesto y otra que esas incidencias se produzcan de forma sistemática.

Se ha convertido ya en algo comúnmente aceptado que las entregas no sean limpias y que se tenga que iterar varias veces hasta alcanzar una versión aceptable para pasar a producción, cuando no iterar sobre versiones que han llegado a producción.

Os lo aseguro, vale la pena hacer testing (bien hecho), invertir esfuerzo en ello, el que sea necesario.

Cuántas veces se me viene a la cabeza la famosa cita de Boris Beizer: “Una amenaza bien vale mil pruebas“.