El creador de menéame, Ricardo Gallí, escribió hace unos días un artículo en su blog bastante interesante sobre lo que respecta a la llamada Ingeniería del Software. Ricardo sostiene que el título de "ingeniería" ha sido dado de forma errónea al desarrollo de software y, en muchos aspectos, tiene razón.

Rescato la lista que él mismo recopiló de Tom DeMarco, sobre un artículo de opinión publicado bajo el título Software Engineering: An Idea Whose Time Has Come and Gone? (Ingeniería del Software: ¿Una idea cuyo tiempo pasó?), hablando de su libro:

• Hoy en día todos comprendemos que las métricas de software cuestan dinero y tiempo, y que deben ser usadas con moderación.
• El desarrollo de software es inherentemente diferente de las ciencias naturales tales como la física, por lo que sus métricas son mucho menos precisas para capturar lo que deben describir.
• La frase más citada del libro es No puedes controlar lo que no puedes medir. Esta frase contiene una verdad real, pero cada vez me sentía más incómodo con el uso que hice de ella. Está implícita en la frase (y en título del libro) que el control es un aspecto importante, quizás el más importante, de cualquier proyecto de software. Pero no lo es.
• Muchos proyectos se han realizado sin demasiado control pero han generado productos maravillosos tales como Google Earth o la Wikipedia.
• Esto nos lleva a la desagradable conclusión: el control estricto es algo que importa mucho en proyectos relativamente inútiles y mucho menos en proyectos útiles. Sugiere que mientras más te enfoques en el control aumenta la probabilidad de que estás trabajando en un proyecto que se esfuerza por generar algo de valor relativamente menor.
• ¿Estoy diciendo que está bien ejecutar proyectos sin control o con un control relativamente menor? Casi. Estoy sugiriendo que deberíamos seleccionar primero los proyectos cuyo control preciso no importe demasiado.
• Estoy llegando gradualmente a la conclusión: el momento de la ingeniería del software vino y se fue.
• En los últimos 40 años nos hemos torturado por nuestra ineptitud en acabar proyectos a tiempo y con el presupuesto previsto. Pero como sugerí antes, no debería haber sido el objetivo supremo.
• El objetivo más importante es la transformación, crear software que cambie el mundo, o que transforme una empresa, o la forma en que se hace negocio.
• El desarrollo de software es y será siempre algo experimental. Lo construcción real de software no es necesariamente experimental, pero sí lo es su concepción. Allí deberíamos enfocar nuestros esfuerzos. Allí es donde deberíamos haberlo hecho siempre.

Esto nos indica que el software debe de realizarse con un fin concreto, con una utilidad en mente y, el hecho de prefijar, fijar o realizar unos requisitos sobre él, no son más que el ejercicio de la práctica y las necesidades reales que quieran cubrirse de forma eficiente. Cambiando algo significativamente.

Otro aspecto que se enfatiza es el tema del control. ¿El control excesivo es perjudicial para un proyecto de "ingeniería" del software?

Lo que es casi obvio para la mayoría de profesionales, es que el desarrollo de proyectos en cadena es bueno emplear metodologías tradicionales, puesto que son cosas que se han podido medir durante mucho tiempo, no suelen cambiar mucho y se realizan siempre de la misma forma. E igualmente, el equipo humano, su creatividad y destreza no son tan importantes como el procedimiento marcado para realizar el programa en el tiempo estimado.

Por otro lado, los proyectos a medida, que se realizan con una especificación de requisitos variable y que pueden ir modificándose en el tiempo con la necesidad del cliente, requieren de otro tipo de metodologías que den otro tipo de control a los desarrolladores y mayor libertad a los programadores. En este caso sí es muy importante que los desarrolladores (analistas) sepan cercanamente lo que se hace y cómo se hace, que sepan lo que cuesta realizar el trabajo y, sobre todo, que sean los programadores los que digan lo que van a tardar en cada tarea. Aproximadamente.

Esta última forma es el que más proyectos genera para la industria de creación de software y, dado que la llamada ingeniería es tan liviana en este caso, quizás sí, quizás el nombre no sea todo lo acertado que debiera... quizás necesitemos otro nombre para nombrar lo que hacemos.