archivo

Archivos diarios: agosto 29, 2011

El desarrollo de software es una profesión infravalorada. El glamour de los que se han hecho millonarios en este negocio es cosa de unos cuantos, la inmensa mayoría de los que nos dedicamos a esto lo hacemos para intentar vivir dignamente y tras pasar unos cuantos años de mileuriesmo.

Y nuestra profesión ha llegado a este extremo por culpa nuestra. Siempre es más fácil echar la culpa a los demás, pero la verdad es que nosotros no hemos hecho mucho por dignificar nuestra profesión. Son muchos los pasos que hay que dar para recuperar poco a poco ese larguísimo camino perdido, uno de ellos es el de preocuparnos realmente por obtener productos de calidad.

Mientras se asocie el desarrollo de software a chapuza no levantaremos cabeza.

El desarrollo de software es complejo, muy complejo, de eso no cabe duda, pero tampoco la hay de que se pueden hacer las cosas mucho mejor. El término crisis del software no se acuñó por casualidad, como tampoco lo es que hoy en día siga plenamente vigente.

La siguiente reflexión de Weinberg no me parece muy afortunada, en el sentido de que compara dos disciplinas muy diferentes, en las que existe una diferencia de miles de años de experiencia entre una y otra y en donde la construcción dista también mucho de alcanzar la perfección (traducción libre): “Si los constructores construyeran edificios de la misma forma en que los programadores hacen los programas, el primer pájaro carpintero que se presente podría destruir la civilización”.

Pese a que no me parezca justa una sentencia como esa la he puesto como un ejemplo para mostrar qué visión se tiene sobre nuestro trabajo.

Gerald (Jerry) Weinberg trabajó como desarrollador de software en IBM entre los años 1956 y 1969, donde compaginó esta labor con la de profesor universitario. En el año 1969 fundó una consultora orientada a ayudar a la gestión de los procesos de cambio en las organizaciones dedicadas a la ingeniería del software con un enfoque más humano.

Jerry Weinberg, entendía, como más tarde vinieron a demostrar las metodologías ágiles que lo más importante en el desarrollo de software son las personas y que si no se gestionaban y entendían de la manera adecuada todo el trabajo que venía detrás se vería inevitablemente afectado.

Además de este trabajo, ha sido conferenciante, miembro de varias organizaciones de reconocido prestigio, ha escrito numerosos artículos y más de treinta libros.

Entre sus obras destaca una que escribió en el año 1971 denominada: “The Psychology of Computer Programming”.

Son innumerables las citas de este autor, en este y en próximos artículos analizaré varias de ellas.

Sobre la visión que tienen gran parte de los desarrolladores de software sobre la documentación, Jerry Weinberg realiza la siguiente reflexión: “La documentación es el aceite de ricino de la programación”.

Precisamente uno de los problemas que tenemos en nuestro negocio es precisamente entender que la documentación es una piedra que tenemos en el zapato en cada proyecto, cuando realmente no es así, sino que es un instrumento inherente al proceso de desarrollo.

La documentación se convierte en un problema cuando se convierte en un factor externo al desarrollo, como si fuera un elemento independiente. En ese momento la documentación pierde gran parte de su interés y del retorno del esfuerzo invertido en realizarla.

La inteligencia es un factor importante para destacar en cualquier profesión, negarlo sería simplemente ponernos una venda en los ojos. Sin embargo, en el mundo del desarrollo de software son otras muchas las variables que intervienen, las cuales son además distintas en función del rol que se desempeñe en la organización.

La capacidad de análisis, de aprender pronto, de asociar experiencia, conocimiento con una determinada situación están ligadas a la capacidad intelectual de cada uno, sin embargo, esa experiencia, ese conocimiento no viene solo, es fruto del trabajo realizado hasta el momento y de las características del mismo.

Además, son necesarias más cualidades como la productividad, la capacidad de trabajar en equipo, la capacidad de tratar con otras personas, la capacidad de comunicar, la capacidad de superar situaciones de presión, la capacidad de salir adelante en los malos momentos, la capacidad de conocer nuestros límites, la capacidad de reconocer y aprender de nuestros errores, etc…

Un proyecto de desarrollo de software es una entidad en la que producen errores continuamente, desde que se concibe el proyecto y se negocia hasta que termina. Todos comenten errores, desde el más alto directivo que interviene en el proyecto hasta quien está empezando en este negocio.

Algunos errores condicionarán el proyecto en su conjunto, sobre todos los realizados en las etapas iniciales del mismo y otros afectarán directamente al producto que llega a producción.

Cometer errores, por tanto, es algo natural dentro del desarrollo de software. Claro que hay personas o equipos de proyecto que se equivocan menos pero no hay nadie infalible, hasta ese técnico excepcional que conoces comete errores.

Lo importante, no es solo minimizar los errores que se comenten (que sea algo natural en el proceso de desarrollo no quiere decir que no sea algo en lo que se pueda y se deba mejorar), sino tener la capacidad de corregirlos lo antes posible, de manera que su impacto en el proyecto no sea importante.

No todos los errores son iguales, hay algunos que resultan muy complicados de remontar, como aquellos que dan lugar a tener que realizar un proyecto sin los medios adecuados y sin el tiempo que se necesitaría para hacerlo, dando lugar a un Death March Project. Otros producen daños que pueden ser irreparables, como por ejemplo en sistemas críticos si no son detectados antes de la puesta en producción del software.

Para minimizar los errores que se cometen, para corregirlos cuanto antes, para adaptar los mecanismos de testing a la naturaleza del proyecto, tenemos las buenas prácticas, las metodologías y los controles necesarios para verificar que realmente se están realizando de manera adecuada.

Esto es ágil, no lo es desarrollar sin un sentido y sin un método. La agilidad está por encima de los procesos, cierto, pero no los ignora y hay una sutil diferencia entre una cosa y otra.

En el último artículo que publiqué sobre la temática de los casos de uso, un lector me dejó el siguiente enlace (en inglés): Cómo implementar operaciones CRUD en UML, en el que como respuesta se indica que si la representación en los diagramas/modelos no aportaba valor, tal vez la mejor solución pasaba por no representarlos.

Y me parece una buena propuesta, ¿por qué no?, sin embargo sí que soy partidario que cómo mínimo, en el caso de los casos de uso se estereotipen los que se correspondan a gestiones CRUD y que se haga referencia a un guía, libro blanco, etc…, de la organización en la que se especifique cómo debería ser el comportamiento en este caso, en los maestros/detalle o en cualquier otro tipo de figura que se quiera estandarizar.

Los generadores de código suelen resolver la problemática del CRUD, sin embargo, no todos la resuelven de la misma manera. Si existen diversas empresas que desarrollan para tu organización, te encontrarás con que utilizan diversos generadores y la solución de salida será distinta, algo que en la medida de lo posible resulta interesante evitar.