Algunas citas del libro Facts and fallacies of software engineering de Robert Glass

Robert L. Glass es un importante autor de publicaciones y libros centradas principalmente en la ingeniería del software. En el campo profesional empezó a realizar tareas de desarrollador de software allá por el año 1954 y se incorporó al mundo académico en la década de los setenta, realizando labores docentes y de investigación.

Sus últimos libros están editados en el año 2006, por lo que podemos hacernos una idea de su amplia experiencia y trayectoria en el mundo del desarrollo de software, lo que hace que sus opiniones sean muy respetadas.

En el año 2003 se publicó el libro «Facts and fallacies of software engineering» sobre el cual voy a poner a continuación algunas citas interesantes que se encuentran en el mismo (hay muchísimas más, tan interesantes o más que las que voy a indicar aquí, por lo que os recomiendo que si tenéis la oportunidad os hagáis con el libro):

– El factor más importante en el desarrollo de software es la calidad de los programadores.

– Los buenos programadores son por lo menos 28 veces mejores que los malos programadores.

– El entorno de trabajo tiene un profundo impacto en la productividad y en la calidad.

– Una de las dos causas más comunes de que un proyecto vaya mal son las malas estimaciones.

– Una de las dos causas más comunes de que un proyecto vaya mal son los requisitos inestables.

– Corregir errores es la fase que más tiempo consume en el ciclo de vida del software.

– El mantenimiento supone entre el 40 y el 80% del coste del software del cual el 60% suelen ser mejoras.

Simplificando indicadores en los acuerdos de nivel de servicio

La experiencia me ha enseñado que no por tener muchos indicadores se va a tener mejor controlado el acuerdo de nivel de servicio que se pacte con un determinado proveedor, es más, lo más probable es que cuanto más indicadores se posea será más complicado hacer esta tarea y más árboles te impedirán ver adecuadamente el bosque, ya que se corre el riesgo de perder más tiempo mirando alertas que en darte cuenta que algo realmente está fallando y en ponerle el remedio necesario.

A todos nos encanta poner alertas, pero al final nos daremos cuenta que en lugar de simplificar, complican.

Lo importante es definir aquellos indicadores mínimos que permitan controlar el servicio. Lo más probable es que al principio te equivoques e incluyas indicadores que no van a servir para nada o que son muy complicados de medir objetivamente, también es muy probable que hayas olvidado de introducir alguno que permita medir carencias que estás descubriendo en el servicio. Por ese motivo, los indicadores deben ser algo vivo en el servicio y ajustarse a lo que se va necesitando y a la realidad (tampoco sirve de nada poner objetivos inalcanzables porque provocará desazón tanto en un lado como en otro). Es importante señalar que la realidad tiene que venir determinada por lo que resulta razonable, tanto para un lado como para el otro. La realidad también depende del presupuesto que exista.

En cualquier caso no hay que obsesionarse con acertar a la primera ya que por mucha voluntad que se ponga siempre existirá una solución mejor que la que teóricamente has pensado, ya que la realidad es algo bien distinto. Para llegar a un destino hay que dar un primer paso y ese está en la primera propuesta de indicadores, ¿se perderá tiempo por tener que retocar los indicadores y los métodos de cálculo? por supuesto que sí y eso hay que asumirlo, pero mejor así que conservarlos si éstos no cumplen con su propósito. Todo es mejorable, también lo será tu segunda, tu tercera, etc… propuesta de indicadores. Lo importante no es que haya que rectificar, sino entender que se rectifica con el objetivo de seguir mejorando.

Cuando los indicadores pueden cambiar requiere de un acuerdo entre cliente y proveedor (otra cosa bien distinta es que se lleve años trabajando en un tema y se tenga muy claro cuáles son los indicadores, pero eso no lo vamos a tener siempre tan claro, sobre todo conociendo lo variable que es el mundo del desarrollo de software y que no siempre vamos a contar con un mismo presupuesto, en unos casos porque no se pueda y en otros porque no sea necesario), como es lógico el cliente querrá apretar y el proveedor respirar un poco más, pero si se es razonable se terminará llegando a un acuerdo.