archivo

Archivo de la etiqueta: Gerald M. Weinberg

Como toda cadena, el desarrollo de software tenderá a romperse por el eslabón más débil. Desde esa perspectiva todas las actividades que componen un proyecto de desarrollo de software son importantes para conseguir un buen resultado y la ejecución técnica, por tanto también lo es.

Es cierto que hay otros factores que considero más importantes para el éxito del proyecto ya que condicionan todas sus actividades pero eso no debe hacer que se preste menos atención al proceso de programación porque de la calidad de este trabajo dependerá la existencia de menos errores, la mayor adecuación a las especificaciones del usuario, aspectos no funcionales como el rendimiento, la seguridad, etc… y la deuda técnica que condicionará en gran medida el mantenimiento del sistema y la productividad de dicha actividad.

Es posible que programar es algo que esté al alcance de cualquiera pero programar bien es muy complicado, se requiere mucha formación, experiencia y disciplina. Por ese motivo pienso que si a un desarrollador le gusta programar y es bueno en ello, su carrera profesional se tiene que orientar en ese sentido (visión horizontal) en lugar de intentar proyectarlo hacia determinados puestos donde lo mismo su rendimiento puede ser mediocre.

Y sí, programar bien es muy difícil. Sobre esto, Gerald Marvin Weinberg tiene dos reflexiones muy esclarecedoras:

– “La programación es de lejos la actividad intelectual más difícil que el ser humano ha intentado hacer jamás”.
– “Un bit erróneo en 1.000.000.000.0000 puede arruinar todo, matar personas o algo peor. ¿En qué otro ámbito se requiere ese nivel de precisión?”.

En algún artículo he tratado este asunto, son muchas las cualidades las que debe tener un buen desarrollador de software. Probablemente muy pocas personas o ninguna saque matrícula de honor en todas las variables y también pasa que existen determinados tipos de proyectos donde alguien puede obtener extraordinarios resultados, pero que en el momento en que cambia la tipología del mismo, el tipo de cliente, etc… los resultados se vuelven más normales o incluso negativos.

Conozco a muchos profesionales de la informática que valoran la capacidad intelectual de sus técnicos por encima de otras cualidades. Es importante, pero para mi es una cualidad más, que no vale más que otras muchas.

Sobre esto, hay una interesante reflexión de Gerald Marvin Weinberg: “Tener un alto cociente intelectual es como tener una CPU con una terrible velocidad de computación. Es un gran activo para la resolución de problemas, siempre y cuando los mismos no tengan una gran cantidad de entradas y salidas”.

La experiencia es importante. En el desarrollo de software importantísima. Muchas de las ideas utópicas que teníamos sobre lo que era este negocio y muchos de los conocimientos adquiridos en nuestros estudios se estrellan cuando se pasa de la teoría a la práctica.

Experiencia no es acumular años en un determinado trabajo. La experiencia no es lineal, sino que realmente se va adquiriendo a través de los proyectos en los que estamos trabajando, de todo lo que pasa en los mismos y de las personas que conocemos y con las que colaboramos. La experiencia requiere aprender de los errores. La experiencia también requiere humildad.

Humildad para poder seguir aprendiendo de otros, para que puedan prestarte su ayuda, su opinión, sus conocimientos, sus propias experiencias.

Sobre este asunto Gerald Marvin Weinberg realiza la siguiente reflexión: “La experiencia no necesariamente enseña nada”

La experiencia cambia tu percepción del mundo, en este caso, de los proyectos de desarrollo de software, pero no necesariamente soluciona nada, no necesariamente tiene por qué tener las claves para que todo vaya bien. Ahí es donde hay que demostrar esa humildad, en saber que se ha evolucionado, que se ha alcanzado un conocimiento que está más allá de los libros, pero también en ser conscientes de que nuestra experiencia, nuestro conocimiento, está para servir al proyecto sin que se tenga por qué cerrar puertas a otros puntos de vistas, independientemente del rol y experiencia que tengan los mismos.

No debería ser así porque realmente no hay nada que justifique que el software se tenga que ir deteriorando conforme se van realizando tareas de mantenimiento con el mismo. Sin embargo todos estamos hartos de ver gráficas con el número de errores de un software que llegado a un punto empiezan a crecer de nuevo de manera lenta, pero continua.

Algunos de los motivos pueden ser los siguientes:

– El software desarrollado tiene una importante deuda técnica lo que complica las tareas de mantenimiento.

– Se dispone de poco tiempo para poder realizar mantenimientos correctivos o evolutivos por lo que la consecuencia es eliminar el problema cuanto antes, lo que da lugar a parches que solucionan el problema pero incrementan la deuda técnica del producto.

– El software no para de crecer en funcionalidades incrementándose su complejidad.

Sobre el deterioro del software, Weinberg tiene la siguiente reflexión: “No hay un código tan grande, retorcido o complejo que el mantenimiento no puede empeorar”.

Si la finalidad última de un sistema de información es satisfacer las expectativas de los usuarios materializada en la informatización de un proceso o de una serie de procesos que permita realizar su trabajo con mayor eficiencia y productividad y/o la organización se beneficie mediante el almacenamiento y automatización de la información que se maneja, sin embargo ¿qué pasa cuando los usuarios no se sienten identificado con el problema o simplemente sienten que no existe un problema?.

Pues pasa que el proyecto para ellos pasa a ser algo secundario, cuando no algo sobre lo que poner todas las trabas posibles con el objeto de que no llegue a ningún sitio. ¿Acaso no conocemos todos proyectos que no han ido a ningún lado? Pues aquí una de las principales causas (junto a una mala ejecución de los mismos).

Por eso soy de la opinión de que no es misión de un departamento TIC de una organización crear necesidades ni en usuarios ni en directivos, sino que las necesidades deben ser expresadas por ellos y una vez hecho eso comprometerse e implicarse en el proyecto desde el principio hasta el final.

Sobre este tema Weinberg realiza una reflexión interesante cuando comenta (traducción libre): “Al final de todo, no hay mucha gente que quiera ver sus problemas resueltos”.

Ya he escrito algunos artículos sobre la problemática de considerar imprescindibles a determinadas personas en una organización o que efectivamente puedan llegar a ser difíciles de sustituir sin un impacto importante.

Llegar a ese punto es fomentar el individualismo, la creación de cotos privados, de parcelas de “poder”, cuando el desarrollo de software es un trabajo en equipo o por lo menos debería serlo para intentar conseguir unos resultados mejores (es cierto que se habla demasiado de las bondades del trabajo en equipo en el desarrollo de software, que sabemos que funciona y que ofrece buenos resultados y sin embargo la organización predominante dentro y fuera del proyecto son los grupitos que resulta hasta más perjudicial que el individualismo).

También he comentado en alguna ocasión que el principal responsable de la existencia de imprescindibles es la propia organización que no ha sabido retener o repercutir su conocimiento en más personas del equipo.

Hay que entender que en toda organización destacan determinadas personas, es hasta positivo que así sea, pero una cosa es destacar y aprovechar todo ese potencial y otra que exista dependencia del mismo.

Sobre este hecho Weinberg realiza la siguiente reflexión: “Si un gestor quiere ejecutar un proyecto de manera estable haría bien en seguir la siguiente máxima: si un programador es indispensable, deshazte de él lo antes posible”.

Uno de los aspectos más complicados del testing consiste en definir hasta dónde se va a llegar, es decir, qué tipo de pruebas realizar y con qué intensidad, ya que todo el software no tiene la misma criticidad, los mismos recursos para su desarrollo, los mismos plazos, etc…

Es un error aplicar el mismo nivel de testing a todos los productos, ya que podemos pecar por exceso o por defecto (siempre mejor, como es lógico el exceso) y además hay que tener en cuenta que el testing se debería medir más por su efectividad y por su calidad que por el tiempo dedicado al mismo, si bien, se entiende que un equipo formado, aplicando una serie de metodologías y utilizando una serie de herramientas, mantendrá un nivel de efectividad más o menos regular por unidad de tiempo.

A lo anterior hay que añadir que el testing se debe realizar en todo el proceso de desarrollo y no solo al final y que el mismo equipo de proyecto debe participar en el mismo mediante la aplicación de pruebas unitarias, integración continua, pruebas funcionales, verificaciones continuas con el usuario y obtención e implementación del feedback, etc…, independientemente de que existan una serie de profesionales que sean especialistas en realizar este tipo de trabajo.

El testing es muy importante y no una disciplina secundaria, no es algo que se debiera infravalorar, como en el mundo de la programación hay programadores buenos, malos y regulares, lo mismo pasa con los testers. Un producto que llega a producción con errores graves va a costar dinero, de una u otra forma. En algunos casos estos errores serán críticos y el coste será elevadísimo en otros casos provocará un parón en el servicio que no es poco.

Resulta muy interesante la siguiente cita de Weinberg porque refleja bien a las claras lo crítico que resulta en muchas ocasiones el proceso de testing y lo complicado que resulta establecer sus límites (traducción libre): “En septiembre de 1962, saltó a la luz una noticia que indicaba que un cohete de 18 millones de dolares había sido destruido en pleno vuelo debido a un simple guión que faltaba en un programa. La naturaleza de la programación es así, ya que no existe relación entre el tamaño del error y los problemas que causa. Por tanto, es difícil definir cualquier objetivo en el proceso de testing, sin llegar a la eliminación de todos los errores, algo que resulta imposible”.