Decía Boehmn que aquello de que “quienes no pueden recordar el pasado están condenados a repetirlo” es una verdad a medias, ya que el pasado también incluye historias de éxito, y “si no somos conscientes de ellas estaremos frecuentemente condenados a no repetirlas”. Y a este respecto, comentábamos en algunos retos de los profesionales del software (1/4) que uno de los, en mi opinión, retos de los profesionales del desarrollo software es mejorar nuestra “memoria histórica”, en el sentido de conocer algo más del pasado y evolución de nuestra ingeniería del software.

Conocer poco el pasado de la ingeniería del software nos lleva, por ejemplo, a ser más vulnerables frente una práctica demasiado común en nuestra profesión: que nos ofrezcan, e intenten “vender”, antiguas prácticas y técnicas como si fueran de reciente aparición, añadiendoles pequeños cambios y un nuevo nombre. Sorprende escuchar en foros, eventos, reuniones, etc., como antiguas prácticas de ingeniería software se mencionan como algo novedoso, que acaba de aparecer para resolver los problemas del desarrollo; y muchas veces sorprende enterarse de que, por ejemplo:

- Las fábricas de software… son un concepto que aparece en los años 60.

- El “pair programming”… comenzó a utilizarlo Brooks en los 50, como se cita en “Pair programming illuminated”.

- La buena práctica de que la documentación del código (o parte) esté en el propio código… es de 1984, práctica también llamada “literate programming” de Knuth.

- Las primeras prácticas ágiles… son de los años 60, y el primer método ágil fue DSDM de 1994, cinco años antes que XP.

-El ciclo de vida iterativo e incremental, que recomiendan metodologías ágiles como SCRUM… comienza a utilizarse en los 60.

- La importancia de la participación del usuario final durante el desarrollo software… comenzó a mencionarla Ehn en 1988.

- La cada vez más de moda ISO 15504 aparece hace 15 años, en 1995

- (si algun@ tiene otro dato que crea importante añadir a esta lista sería interesante añadirlo como comentario a este post)

Desconocer parte del pasado y evolución de nuestra ingeniería del software también provoca que, a veces, se siga aún creyendo en prácticas que hace mucho tiempo la experiencia dijo que no funcionaban, como el clásico de intentar solucionar los problemas de tiempo en proyectos software añadiendo más personas a un proyecto ya en marcha. O a que aún se siga creyendo en los “silver bullets”. O a que olvidemos buenas prácticas que llevan ahí desde hace mucho tiempo (como comentábamos en el post del veterano ciclo de vida iterativo e incremental).

La mayoría de las mejores y más prometedoras ideas de la ingeniería del software no vendrán en el futuro… llevan con nosotros desde hace mucho tiempo.

Otras entradas relacionadas con esta:

1. Algunos retos de los profesionales del software (1/4)
2. SEMAT: Propuestas para refundar la ingeniería software
3. Tendencias, y algunos datos económicos, en la industria del desarrollo software en España