¿La ingeniería de software ha muerto?

Después de asesinar a Java el webmundo ha elegido su próxima víctima: la Ingeniería de software.

A través de un artículo en Coding Horror leo un artículo del autor de Controlling Software Projects: Management, Measurement, and Estimates en el que afirma:

I'm gradually coming to the conclusion that software engineering is an idea whose time has come and gone.

Recomiendo la lectura de ambos artículos: el original y el de CodingHorror.

¿Qué opináis? ¿Matamos o no matamos a la ingeniería de software?

#1   

Es una lectura interesante, pero para quien no quiera leer todo (o el inglés le cueste), la idea es que todo eso que se monta alrededor del proyecto para tener algún tipo de sensación de control, no sirve de nada. El desarrollo de software es siempre experimental. Para mi se resume todo en lo que dice Jeff Atwood:

what we do is craftsmanship, not engineering

Sinceramente comparto esa idea al 100%. No se trata de matar nada, sino más bien de reconocer qué es lo que hacemos y cómo lo hacemos. Para mi, siempre ha sido artesanía, no ingeniería.

Por cierto, aprovecho para recomendar algo: Creo que es en La Sexta, que los sábados y/o domingos por la mañana (a media mañana, no hace falta madrugar :)) ponen unos programas sobre ingeniería. Ingeniería civil, naval, aeronáutica... Creo que puede ser interesante para alguno ver algún documental de esos.

#2   

Coincido contigo en que pienso que el desarrollo de software es artesanía, no ingeniería.

#3   

Ricardo Galli se hace eco en ¿”Ingeniería” del software? Ahora vienen los mea culpa

Un saludo!

#4   

Joer, o soy yo que soy torpe o la moderación de ese blog es lo más estúpido del mundo. Porque, que no salga un mensaje razonable como lo que había escrito y sin embargo salga esa cantidad de gente que piensa que insultar es una forma de argumentación, no me parece normal xD

En fin, ya paso de escribir en el blog de R.Galli.

#5   

Hombre, la ingeniería del software tal y como nos la enseñaron en la escuela (a mí por lo menos) ha muerto, sí; pocos diagramas UML he hecho de diseño detallado para abajo, pocos tochos de documentación infumable también, incluso el código tiene muy pocos comentarios (hay autores que incluso animan a comentar lo menos posible el código, y postulan que si hay demasiados comentarios, es que algo no se entiende o no está bien), no sigo metodologías monolíticas ni RUP (que para el caso es casi lo mismo)... en cierto modo las metodologías ágiles están enterrando quizá un poco todas estas metodologías que han probado en bastantes ocasiones su ineficacia.

No digo que las metodologías ágiles vayan a ser la panacea, ojo, ni mucho menos. Ya veremos.

#6   

Aquí la pregunta debía a ver sido ¿por que no se murió antes? y es que urgía la herencia del muerto, la metodologías ágiles y todos esos inventos que ojala cada vez mas nos hagan la vida fácil.

Lo peor va a ser cuando alguien llegue y diga "no, si no se a muerto" y entonces vamos a tener palos, piedras y cuchillos para hacernos justicia por mano propia xD

#7   

Jajaja UAO, que mal tan grande leas ha hecho la Ing. Del software? Espero que los palos y piedras no sean para mi, soy una novata en el area y tenia como proposito terminar la uni para hacer una maestria en ing. de software, pero me gustaria que me cuenten las experiencias que los llevan a pensar así.

#8   

@Miniproject:

No se trata de que "la ingeniería de software nos haya hecho algún mal", sino de ser conscientes de lo que hacemos.

En mi caso, he estudiado Ingeniería Industrial y creo tener una cierta idea de lo que es la Ingeniería. En mi modesta opinión, la Ingeniería se parece poco a lo que hacemos cuando desarrollamos software. El desarrollo de software se parece mucho más a lo que llamamos artesanía.

Es cierto que algunas de las técnicas empleadas en la Ingeniería se pueden aplicar -en cierta medida- al desarrollo de software. Por ejemplo, podemos utilizar técnicas de planificación y seguimiento de proyectos. Con algunas limitaciones, como el hecho de que las estimaciones de tiempos son algo más difíciles, pero es posible dividir el trabajo en tareas, estas en subtareas... Podemos establecer prioridades, dependencias entre tareas... Podemos usar un diagrama PERT o Gantt del proyecto. Las estimaciones como decía nos limitan un poco en la utilidad de esto porque las desviaciones de tiempos y plazos que se producen en los proyectos de software son, en general, notablemente mayores que las desviaciones que se producen en proyectos de otros tipos.

Bien. Esto, como digo, tiene limitaciones. Pero incluso aunque lo tuviéramos más controlado y pudiéramos aplicarlo mejor, esto no hace que sea Ingeniería. Quiero decir, planificar y seguir algo, no hace que ese algo sea ingeniería. Mi madre, aficionada a la costura, planifica las cosas cuando va a hacerse por ejemplo una chaqueta. Podríamos, por qué no, hacer una planificación bastante precisa, incluso más que del desarrollo de un software, de la creación de una chaqueta. Ella no lo hace, pero sería bastante sencillo preguntarle las diferentes tareas, tiempos, etc, y hacer nuestra planificación. Eso no hace que lo que es, claramente, artesanía por parte de mi madre, se convierta de algún modo en ingeniería. Creo que nadie diría lo contrario, ¿no?

En el desarrollo de software podemos aplicar metodologías, sistemas de calidad, mecanismos de control... Pero, como digo, que podamos aplicar una determinada técnica a una actividad no quiere decir que esa actividad se convierta en ingeniería. Ni siquiera aunque esa técnica sea propia de la ingeniería.

Entonces ¿qué es lo que hace que la ingeniería sea ingeniería? Y ¿Qué es lo que hace que una actividad cualquiera lo sea o no lo sea?

La ingeniería se caracteriza por una serie de conceptos que van más allá del uso de una u otra técnica determinada. Más aún, va mucho más allá de las metodologías de planificación.

Para mi, hay dos objetos que sirven muy bien para comprender qué es la ingeniería. Uno es el catálogo y otro es la tabla. Ambos cumplen una función muy similar.

Un catálogo es lo que te permite elegir una u otra pieza en función de un número limitado de parámetros. Es decir, si necesitas determinada pieza (pongamos un rodamiento) lo que haces es ir al catálogo de SKF. Ahí, con sólo un puñado de parámetros puedes elegir el rodamiento que necesitas porque saber que soporta la carga estática que necesitas y la carga dinámica que necesitas y es capaz de girar a las revoluciones que necesitas.

La tabla cumple una función muy parecida al catálogo, salvo que opera sobre una determinada formula matemática. Es decir, que cuando tienes que meter en tu sistema de control climático un intercambiador de calor de tubos, el problema del cálculo del intercambiador es tremendamente complejo. Resolverlo con precisión es un trabajo enorme. Pero también innecesario. Porque estudiando la fórmula se ha llegado a una serie de simplificaciones que nos permiten ir a una tablas en las que entramos con un número limitado de parámetros que definen nuestro problema y podemos obtener una aproximación conocida y confiable del número y longitud de tubos que necesitamos. (Luego con eso podemos ir a un catálogo y elegir un cambiador lo más parecido posible o hacer uno a medida)

Ambos elementos, catálogo y tabla, representan -en mi muy modesta opinión- una serie de ideas fundamentales de la ingeniería.

En primer lugar la repetibilidad. Un rodamiento es un problema de ingeniería que es ampliamente conocido y que, simplemente, está resuelto. No necesitamos resolverlo cada vez. Vamos al catálogo y nos encontramos la solución. Más aún, ese catálogo nos da unos parámetros comprobados y confiables. Y, quizá incluso más importante, nos da unas limitaciones y unas tolerancias que podemos medir y garantizar. Sabemos que un condensador determinado de 10μF tiene unas temperaturas en las que puede operar y tiene una determinada curva de respuesta y demás. Sabemos que su comportamiento dentro de sus límites operativos es ese y sabemos cuánto puede desviarse de ese comportamiento.

Por otro lado, catálogo y tabla son la representación de un importante trabajo que hay detrás hasta llegar a ellos. Es un trabajo de diseño, de cálculos, de prototipos, de pruebas, de sistemas de fabricación, de medidas de calidad, que lleva a un elemento totalmente controlado. Es decir, SKF tiene un proceso controlado y nos ofrece a nosotros un elemento ya solucionado y parametrizado. Ese trabajo también es la ingeniería. Es un trabajo de reducción de los problemas a sus parámetros fundamentales. Problemas que, en sí mismos, son complejos (calcular una solución precisa y completa de un rodamiento es tremendamente complicado) se van reduciendo en complejidad para una serie de casos determinados: Establecemos, por ejemplo, una serie de tipos de rodamiento (de bolas, de conos, de cilindros, de agujas...), para cada uno determinamos una serie de parámetros que definen el problema y solucionamos el problema en un número limitado de casos. Reducimos la complejidad en varios órdenes de magnitud y lo dejamos en un puñado de parámetros. 3, 9... o 20, pero sólo unos cuántos. Y encima sólo damos la solución para unos casos determinados. Diámetro interno de 1, 2, 4, 6... diámetro externo de... 4, 8...

En el desarrollo de software, el catálogo o la tabla son objetos no sólo desconocidos, sino impensables.

¡Ojo! Que alguien podría pensar que una librería (qué sé yo, por ejemplo, libxml) es el equivalente en software del rodamiento. ¡Pero las diferencias son tremendas! Ya de entrada, libxml no es exactamente un problema solucionado, sino que más bien es una herramienta para solucionar. No hemos reducido la esencia del problema a 12 parámetros. No elegimos la función de libxml y ya está. No, en general lo que hacemos es utilizar diversas funciones de libxml para procesar el XML y solucionar ese problema.

Más aún, con el software no hay aproximaciones y tolerancias. Me puede decir alguien los límites operativos de... ¿Spring? ¿O su tolerancia? Incluso admitiendo las diferencias de aplicabilidad de ambos conceptos, ¿realmente alguien me lo puede decir el límite operativo de Rails? Rails pretende ser una de las piezas de software más simplificadas y aún así no conocemos su "capacidad de carga"...

No sólo no lo sabemos, sino que en determinados aspectos ni siquiera es posible saberlo. Y no sólo porque operativamente no lo sepamos, es que además existen aspectos teóricos según los cuales, por ejemplo, no podemos determinar con certeza que cualquier programa esté libre de errores. Pero ¡peor aún! ni siquiera podemos determinar en qué grado de certeza un programa está libre o no de errores.

Sí, sí, oigo a uno ahí al fondo pensando "pruebas unitarias y funcionales". Pero eso sólo controla lo que controla. No determina lo que no controla :) Es decir, podemos saber cuáles son los errores que no tiene, pero no podemos, no sabemos calcular en cuánto puede fallar.

Mirando un poco otro lado de este argumento, también hay que pararse a pensar en qué es lo que hacemos en otras ingenierías y qué es lo que hacemos al desarrollar software. Me refiero a "sobre qué trabajamos". En la ingeniería en general trabajamos fundamentalmente sobre propiedades matemáticas y físicas del mundo real. Una viga soporta unas fuerzas medibles y observables. La capacidad de la viga no depende de mi estado de ánimo, de mi inspiración, de mi capacidad de comprensión del problema. Y precisamente de eso es de lo que depende el software. El desarrollo de software es fundamentalmente una actividad intelectiva. Pensar. Comprender. Entender. Expresar lo que entiendo a través de un trozo de código (o lo que sea). Son actividades que dependen fundamentalmente de mi capacidad de comprensión, de mi capacidad de inspiración, de mi experiencia anterior, incluso de mi estado de ánimo ese día o de que me sienta bien.

Hay una dependencia total del proceso intelectivo de cada una de las personas. De la comunicación entre ellos. De sus estados de ánimo, de cosas como que "se lleven bien". Parece, mucho más que ingeniería, algo casi místico xD Es algo tremendamente personal, piscológico, emocional. Y, aunque podamos controlar en cierta medida esto, es algo inherente al problema. Estamos tratando con ideas, con pensamientos. Es imposible desligarlo completamente.

¿Has visto alguna vez un proyecto en el que existen personas con muy diferente capacidad? Quiero decir, que tienes un desarrollador "muy bueno" y otro no tanto. Ya de entrada tenemos el problema de cómo medir esa capacidad, pero lo dejaremos para otra ocasión. Pero lo que vemos ahí muy claramente es cómo el desarrollo de software depende en buena medida de quién lo hace. Es otra razón más que hace que se parezca más a la artesanía que a la ingeniería.

Puffff... bueno, voy a parar ya, que me he liado a escribir y tengo que hacer también otras cosas en la vida xD

#9   

Pues la verdad es que has escrito un pedazo de artículo muy interesante...

Yo creo que la ingeniería de software trata de acercarse a otras ingenierías tratando de adoptar sus técnicas que tan bien funcionan en sus campos, con aspiraciones a controlar mejor el proceso de creación de software.

Otra cosa es que esto sea más o menos acertado. En mi opinión esto no es acertado, o al menos no se pueden adoptar soluciones de otras ingenierías tal cual.

#10   

Fantástico comentario Venkman!

Leyendo a Juan Palacio en navegápolis aprendí que las metodologías en una ingeniería tradicional se centran mucho en los procesos. En una ingeniería tradicional eso funciona. Pero en el software aunque los procesos pueden ser importantes lo es mucho más el talento, la comunicación en el equipo,... Cosas muy difíciles de medir, planificar, estimar.