archivo

Archivos diarios: agosto 27, 2011

Harold (Hal) Abelson es profesor del MIT y ha sido uno de los fundadores de la Free Software Foundation y de Creative Commons. Su trabajo como profesor universitario y su capacidad pedagógica ha sido reconocida a través de diferentes premios.

Gerald Jay Sussman también es profesor del MIT y es coautor junto a Abelson del libro “Structure and Interpretation of Computer Programs”, traducido a diferentes idiomas y texto de referencia para la introducción en la ciencia de la computación en el MIT.

Su visión sobre la programación se basa en el hecho de considerar a los lenguajes como un medio formal para expresar ideas basadas en una metodología en lugar de ser simplemente una forma de indicar a un ordenador qué operaciones realizar.

Por este motivo no es de extrañar que realicen la siguiente reflexión: “Los programas deben ser escritos para que las personas lo lean y solo de paso para que máquinas lo ejecuten”.

¿Hasta que punto hay que esforzarse por hacer por conseguir una codificación fácilmente interpretable por otra persona diferente a la que está desarrollando?, ¿hasta que punto puede apartar la consecución de este objetivo del propósito final de cualquier software que no es otro que cumplir las expectativas del usuario?.

Respuestas a estas preguntas puede haber muchas y probablemente la mayoría de ellas sea válida dentro del ámbito de nuestra experiencia personal.

Como sabéis, soy de la opinión de que no existe calidad del software sin satisfacción del usuario. Si no se cumple esta meta poco importa lo demás. Ahora bien, no es incompatible conseguir un software que esté a la altura de lo que se espera con que el mismo tenga una arquitectura y codificación que permitan tener una deuda técnica aceptable y faciliten la evolución del sistema de información (ya sea en el propio proceso de construcción o en su mantenimiento).

Sin embargo no se suele dar la importancia que se merece a la arquitectura del sistema y a la legibilidad del código ya que todo el esfuerzo está centrado en ejecutar trabajo, en conseguir avances en el proyecto, aunque estos sean más virtuales que reales y aunque un paso atrás obligue a dar después muchos pasos adelante.

Dave Winer es un escritor, emprendedor y desarrollador de software americano con una dilatada y variada trayectoria profesional, centrada principalmente en los campos de la gestión de contenidos, blogs y podcasts.

La suerte es importante. Estar en el sitio adecuado, en el momento adecuado marca muchas veces la diferencia entre conseguir el éxito o no. La suerte está ahí, a veces nos quiere mirar otras veces no.

Yo creo más en el trabajo, en el esfuerzo personal por alcanzar nuestras metas. Después podremos o no conseguir nuestros objetivos, pero siempre será más factible que no intentarlo.

Sobre este tema, Dave Winer realiza la siguiente reflexión (traducción libre): “Para obtener un producto software útil hay que luchar por cada solución y por cada funcionalidad. La suerte influye, pero no se gana por tener suerte sino por haber luchado en cada pulgada”.

Los que nos dedicamos al desarrollo de software tenemos el defecto de que si no vemos acción pensamos que el proyecto no avanza.

La actividad no es sinónimo de avance ya que consiste básicamente en enfocar el esfuerzo en una serie de tareas, sin embargo, si las mismas no son correctas o no son las adecuadas nos encontramos ante una serie de esfuerzos invertidos que no han servido para nada o lo que es lo mismo coste sin retorno.

Cuanto más tiempo dediquemos a comprender el problema mayor será el número de tareas que hagamos que tengan un verdadero valor. A veces la comprensión se obtiene a partir del feedback con el usuario, ya sea con prototipos o con el mismo sistema en funcionamiento.

La actividad es buena si se hace con sentido. Avanzar sin saber muy bien donde se va a acabar no suele traer muy buenos resultados.

Tan negativo resulta en un proyecto de desarrollo de software el exceso de documentación como la carencia de la misma.

La documentación debe ser adecuada a la naturaleza del software que se va a desarrollar y tener utilidad, como mínimo para el momento en que se está realizando el proyecto. Si se pierde el enfoque del momento presente y se centra en la utilidad futura que pueda tener la misma, puede que al final no sea útil ni después ni ahora.

La documentación de un proyecto es un instrumento, no un fin, de igual forma que lo es la ingeniería del software. Si la documentación es un objeto decorativo no es útil, es esfuerzo invertido para obtener muy poco valor a cambio.

Esa es mi opinión sobre la documentación, Edward Nash Yourdon, tiene la suya propia que hace patente en la siguiente reflexión, si bien, estoy seguro que el propio Yourdon matizaría sin duda la misma: “No hay nada más despreciable en el mundo de la programación que un programa sin documentar”.

Pamela Zave es una experta en ingeniería del software (especialmente en el campo de la ingeniería de requisitos) que lleva trabajando desde hace veinte años en AT&T. Ha escrito numerosos artículos, algunos de ellos galardonados con premios. Además es conferenciante y es miembro de importantes comités a nivel internacional.

Si la ingeniería del software añade complejidad a un proyecto de desarrollo de software es que no se está aplicando correctamente, no se sabe aplicar o ambas cosas. Como bien comenta Pamela Zave en la siguiente reflexión: “El propósito de la ingeniería del software es controlar la complejidad, no crearla” y está totalmente en lo cierto.

La ingeniería del software es un instrumento, no un fin, que bien utilizado permite desarrollar software de calidad, aplicando la metodología más adecuada para el proyecto en cuestión, gestionando adecuadamente las personas que intervienen en el mismo y existiendo unos plazos y presupuestos acordes a los objetivos planteados.

Hay muchos sistemas de información que son inherentemente complejos ya que el proceso o procesos que tratan de informatizar son de esa naturaleza.

Pero incluso en estos casos, encontrarnos con demasiadas funcionalidades complejas sobre las que trabajar en paralelo nos debe hacer reflexionar sobre si lo que estamos haciendo lo estamos enfocando adecuadamente:

¿Hay algo que no estamos entendiendo bien y como consecuencia la complejidad de la funcionalidad crece?

¿Estamos incorporando demasiada complejidad a la inherente del proceso?

¿Estamos tratando de abarcar más funcionalidades que las que realmente podemos en este momento?

Demasiados frentes abiertos no se pueden gestionar adecuadamente. En lo posible hay que intentar que sean los menores posibles en un proyecto ya que cuantas más puertas abiertas haya, resultará más difícil enfocar la atención a aspectos concretos y la complejidad del desarrollo aumentará en la misma medida.