Nonsense

Ingeniería del Software

El otro día comenté descuidadamente algo como que cada vez que pasaba por Industriales siempre había alguna cosa que me hacía pensar que a muchos desarrolladores de software (como concepto amplio) les vendría muy bien “un poquito de ingeniería”.

Después por esas cosas que tiene la vida cuando la gente cree que hablas específicamente de ellos me vi envuelto en varias conversaciones que no dieron mucho más de sí. Pero hubo un comentario que se quedó ahí dando vueltas. Venía de lo que había escrito sobre charlas, charlistas y demás. El caso es que alguien me dijo…

el problema es que en la vida, y más en programación, es difícil decir qué es erróneo

…y esto dio origen a una conversación breve que pronto encontró las limitaciones de las metáforas aplicadas.

En diferentes ocasiones a lo largo de los años me he encontrado con esa misma idea del “poquito de ingeniería” dando vueltas en mi cabeza y pidiéndome que la ponga en orden y la deje por escrito. Nunca lo he hecho por esa costumbre que tengo de discutir con las voces de mi cabeza y no dejarlas que me obliguen a hacer cosas así al tuntún. Hoy es un día tan bueno como otro cualquiera y quizá si no lo escribo ahora, ya no lo escriba nunca. No prometo nada ordenado, pero por lo menos quedará algo escrito.

Ingeniería Industrial

Soy ingeniero industrial. Digo esto solo para ponernos en situación, no porque crea que ser ingeniero sea algo importante. La carrera tiene un par de detalles particularmente interesantes (al menos para mi) relacionados con “la Ingeniería”.

En primer lugar es (o por lo menos lo era cuando yo la cursé) uno de los programas de estudio más amplios y diversos. Abarca titulaciones que más adelante se han ido disgregando de la principal precisamente por intentar manejar esa amplitud. La Ingeniería Industrial abarca desde la Ingeniería Química a la Electrónica, pasando por Mecánica, Energía, Materiales o Automatización entre otros. No sé ahora, pero sé que en algunos momentos un ingeniero industrial podía firmar un proyecto de construcción civil (como un ingeniero de caminos o un arquitecto… con algunas limitaciones, eso sí). Esto es relevante porque expresa la visión amplia que tiene del concepto de Ingeniería. No tiene mucha más importancia, claro, y en sexto uno de nuestros excelentes profesores ya nos avisó que la mayoría acabaríamos trabajando en desarrollo de software de alguna forma u otra.

El segundo detalle es que la Ingeniería Industrial es una titulación con una importante raíz que viene de “una especie de artesanía”. Creo que fue en cuarto curso (aunque podría ser en cualquier otro) cuando otro de esos excelentes profesores nos dio la recomendación de respetar mucho la voz de los expertos de fábrica. En España, tradicionalmente, ha existido una industria más o menos familiar y pequeña que defendía su labor con el conocimiento y experiencia de una persona que, con o sin unos estudios y/o titulación específicos, tenía un conocimiento experimental muy profundo de los procesos industriales involucrados. Podría verse en cierta manera como un conocimiento artesano de la tecnología. Desde ese momento me fijé más en que, en la Escuela, conocí a un número pequeño pero apreciable de compañeros que efectivamente venían a prepararse para ser “el ingeniero” (o ingeniera) de la empresa familiar. Pequeñas industrias familiares de este estilo en que muchas veces el padre o el abuelo había sido quien la había originado pero ahora veía que necesitaban una persona con una formación más preparada y no simplemente heredar el conocimiento de ese modo tan artesanal.

Son detalles que a mi me gustan de mi carrera, pero más que eso creo que son detalles que proporcionan una cierta impresión del propio concepto de la Ingeniería en sí. Por supuesto no digo con todo esto que yo tenga una visión especialmente acertada o mejor de la ingeniería de lo que puedan tener otros. Solo explico esto para dar una cierta idea de en qué se basa mi perspectiva.

Catálogos

De hecho, esa visión de qué es la ingeniería que tengo no es una sola sino que tiene diferentes ángulos. Durante una época, cuando surgía el tema, mis pensamientos se iban a un ángulo muy preciso. “La Ingeniería son catálogos”, se podría resumir. Catálogos de rodamientos, tablas de tubos de cambiadores de calor, catálogos de sensores y actuadores, de secciones de cables, de controladores PID, catálogos de materiales y de mil cosas más.

Me gustaban mucho los dos primeros, los rodamientos y los cambiadores, cada uno a su manera. Para que os hagáis una idea, podéis buscar si queréis las ecuaciones que intervienen en un intercambiador de calor. Las que os salgan ahí estarán, seguramente, simplificadas de alguna forma (i.e. imponiendo alguna restricción adicional). Si preferís podéis buscar información sobre cálculo de rodamientos.

Tampoco necesitáis investigar en mucho detalle: Hoy en día “nadie” 1) resuelve esos cálculos. Sería no sólo absurdo sino perfectamente inútil. Si necesitas calcular un rodamiento lo que haces primero es establecer qué tipo de rodamiento necesitas con unas ideas básicas. ¿Debe soportar fuerzas a lo largo del eje? ¿Flexiones? ¿Desalineaciones de ejes? Luego lo que haces es ir a un catálogo. Determinas tus restricciones de parámetros y simplemente buscas el rodamiento existente que te proporciona las prestaciones que necesitas y un poco más. Compras ese rodamiento y en lugar de costarte cada rodamiento de tu máquina X, te cuesta X/100 o X/1000. Si necesitas un intercambiador de calor, el proceso es parecido. Vas a tu tabla con unos cuántos datos iniciales y la tabla te dice cuánta superficie necesitas. Luego vas con eso y algún dato más al catálogo del fabricante y ves que vas a tener que pedir el modelo que sea con tantos tubos de tanta longitud. Si no te cabe de esa longitud, tienes otro con otro número de tubos y diferente longitud. Según el tipo de fluidos tienes unos materiales disponibles u otros.

Muchas ingenierías

Por supuesto la Ingeniería no es eso… O mejor dicho, la Ingeniería no es solo eso. Existen otras muchas actividades involucradas y no todo se basa en mirar catálogos, por supuesto. Pero estoy bastante convencido de que los catálogos, tablas y demás, son un elemento fundamental y muy definitorio de, por lo menos, un aspecto de la Ingeniería.

La Ingeniería también tiene mucho de investigación, de pruebas, de prototipos… y en muchos casos (en los casos más habituales) una separación entre el desarrollo y la producción. Es decir, hay un desarrollo del producto, con sus particularidades, y una fase de proceso de producción del producto (generalmente en masa), con sus diferentes particularidades. A veces hay ingenierías con fases de desarrollo de décadas y otras con fases de desarrollo de meses o semanas. Lo mismo puede ocurrir con las fases de producción. Y la Ingeniería se tiene que preocupar de cada caso y de todos los aspectos del caso.

La Ingeniería (en general) es, además, una actividad que tiene ya una historia y esto ha dado lugar a que necesite preocuparse por todos esos aspectos. Aspectos ambientales y ecológicos, sociales, humanos, económicos… y, obviamente, los puramente tecnológicos o técnicos. Insisto en que, en cierta medida por lo menos, ha sido por necesidad, porque precisamente esa es la misión de la Ingeniería, preocuparse de esas cosas para que la aplicación del conocimiento científico nos dé las soluciones mejores en todos los aspectos.

Puentes, Vehículos Acorazados y Bytes

Como decía, la conversación que mencionaba más arriba pronto encontró las limitaciones de las metáforas y comparaciones. Ya sabemos todos que un puente se parece muy poco a un vehículo acorazado y se parece muchísimo menos a un montón de bytes. Yo saqué lo de los vehículos acorazados, no tanto por esa charla que me había llevado a Industriales, sino porque recordé la historia del M2 Bradley 2) y creo que como proyecto de ingeniería encajaba bastante bien con algunos comentarios típicos cuando hablamos de producir montones de bytes. Que si nos piden cosas que se contradicen, que si cambian los requisitos a la mitad del proyecto, que si quieren que empecemos por el techo…

Eso sí, yo personalmente creo que lo que hacemos a día de hoy cuando construimos nuestros montones de bytes está bastante lejos de ser Ingeniería. Y no lo digo por hacer de menos al desarrollo de software, en absoluto. No lo digo porque sea algo “inferior” sino porque lo veo como algo que, al menos por ahora, es demasiado diferente en algunos aspectos. Y por eso mismo, no pretendo decir que apliquemos todas esas cosas que hace la Ingeniería al desarrollo de software. Ese concepto de los catálogos y las tablas, por ejemplo, siempre lo he encontrado demasiado diferente. Sí, reutilizamos conocimiento usando librerías y plataformas y estándares y lenguajes y… sí, pero la forma de hacerlo es bastante diferente.

De modo que cuando me viene esa idea que me viene, siempre aparece cualificada la aplicación de la Ingeniería al desarrollo de software con ese “un poco de”. Qué bien vendría aplicar un poco de ingeniería al desarrollo de software.

Con un poco de azúcar esa píldora que os dan...

Hay ideas que sí que creo que aplican bien. Un caso claro son los conceptos económicos, donde estoy convencido de que a todos los desarrolladores (sea cual sea su especialización) les vendría bien un poco de aprendizaje y aplicación. Algunos tienen claras las ideas más básicas (por ejemplo, esa idea fundamental de que su objetivo no es hacer un montón de bytes sino resolver un problema) pero hay mucha carencia, si no de conocimiento 3) sí de aplicación. He visto demasiadas veces cómo se desarrollaba ignorando por completo evaluar los diferentes costes. A la gente ya ni siquiera le gusta estimar. Sí, ya sé que hay mucha gente haciéndolo mal y otra mucha aprovechándose de eso para su propio interés. Lo sé. Pero eso no quita que estimar los costes tenga una utilidad real y práctica y que ayude a producir mejores soluciones. Si para evitar problemas tu solución es simplemente ignorarlos y dejarlos a un lado, pues apaga y vámonos.

Más allá de eso, está ese otro argumento de arriba:

el problema es que en la vida, y más en programación, es difícil decir qué es erróneo

Y aquí es donde no puedo evitar entristecerme 4). No tanto por la persona que lo decía, que estoy convencido que es un buen profesional y que quería expresar una idea de tolerancia. Pero sí porque es una idea demasiado extendida y generalizada. Existe una tendencia muy fuerte a pensar, no sólo que todo es correcto, sino que todo es igual de correcto. Que sólo son opiniones y que no hay manera de establecer unos criterios objetivos. Luego Javier argumentaba esta falacia refiriéndose incluso a esa referencia de “en la vida”.

Yo no tengo demasiadas ganas de discutir sobre moralidad, sociedad, humanidad… Mis opiniones en estos temas son irrelevantes y carecen de interés. Pero creo que hablar de esto en lo referido a la programación es suficientemente distinto. El grado de subjetividad es notablemente menor.

Creo también que este relativismo y esta idea de presentar cualquier opinión con el mismo valor, es un peligro claro y un obstáculo directo contra el progreso del desarrollo de software como profesión. Es, sinceramente, una falta de profesionalidad importante. De ahí que piense que nos vendría bien por lo menos un poco de ingeniería.

Personas

Quizá el argumento más relevante o desde luego uno de los más usados dice algo así como que en realidad el desarrollo de software no trata sobre montones de bytes sino que trata sobre personas y que las personas son lo más importante. Algunas variaciones que me he encontrado sobre esto proponían bastante directamente ideas como poner el funcionamiento o el bienestar del equipo por encima de la corrección del código. Todo se puede lleva a un mayor o menor extremismo, supongo.

En cualquier caso creo que estamos mezclando argumentos y, a veces, de formas equivocadas. Tengo muy clara la importancia de las personas, especialmente dada la naturaleza del proceso de creación de montones de bytes que son, de alguna forma, poco más que una alucinación compartida en la que (casi) batimos nuestras alas en un lugar del mundo para que ciertos impulsos electromagnéticos produzcan determinados colores y sonidos en algún otro lugar y alguien, al verlo, aprehenda cierto concepto o resultado que hemos acordado de antemano que significan nuestros colores y sonidos.

Sí, el resultado final tiene apariencia, a veces, de depender mucho de la naturaleza humana involucrada. Y no sólo las personas que utilizan el montón de bytes como producto final, sino también las involucradas en crear ese particular montón de bytes. Es todo muy conceptual, muy cerebral. Y cuando hay personas involucradas tan directamente, soy consciente que algunos criterios se pueden volver más complejos de evaluar. Más aún, soy consciente también de que las personas somos extrañas y tenemos extrañas ideas y comportamientos.

Todo eso lo tengo claro.

Sin embargo, estoy convencido que estamos aplicando estos argumentos del modo equivocado. Es bueno, necesario incluso, tener en cuenta y tratar correctamente a las personas. Esto nunca ha estado en duda. Y si lo ha estado, nunca ha sido desde criterios intrínsecamente relacionados con amontonar bytes. Estos son criterios básicos de nuestra sociedad 5) y como tales, son independientes de otros criterios sí relacionados con amontonar bytes.

Sí que hay criterios objetivos, que pueden ser más sencillos o más complejos, por supuesto, que nos permiten evaluar las bondades o limitaciones de diferentes soluciones. Estamos trabajando en una disciplina eminentemente técnica, con algunos aspectos más complejos más relacionados con las personas… como cualquier ingeniería. Todas las ingenierías tienen en cuenta a las personas y los aspectos relacionados con ellas de forma especial y cuidada. Hay diversos criterios y factores a evaluar siempre. Cada uno tiene su importancia y cada uno debe tratarse con la importancia que tiene. La Ingeniería implica buscar un equilibrio entre todos los factores para alcanzar una solución que satisfaga los objetivos de la mejor forma posible, pero no implica tener que sacrificar factores que son independientes.

Me parece equivocado, por ejemplo, hacer que factores humanos como “la salud del equipo de desarrollo” se pongan por encima de la corrección o validez técnica de la solución. Sí, he tenido conversaciones con personas que defendían exactamente esto. Hablábamos de revisiones de código y me decían que sí, que ellos dejarían pasar código con defectos si peligraba el bienestar del equipo. Me parece difícil de entender que alguien pueda pensar que un equipo que produce defectos sabiéndolo, está sano de alguna forma (ni colectiva, ni individualmente). Pero más que eso, me parece que es una irresponsabilidad profesional, y que no entendemos ni lo que estamos produciendo (el software) ni lo que significa tratar bien a las personas.

Es justo por cosas así por las que todas esas metodologías (ágiles o no), procesos y procedimientos terminan siendo en tantos casos un montaje, una farsa de decirnos unos a otros 6) lo buenos que somos y lo bien que hacemos las cosas, mientras nos hemos olvidado de, precisamente, hacerlas bien. En el fondo, lo que hacemos es re-escribir nuestro relato para sentirnos mejor, aunque no sea real.

Mientras no aprendamos estas cosas, mientras no busquemos expresamente definir criterios, no aprendamos a evaluar y no nos centremos en buscar explícitamente el progreso a un nivel global, me temo que la profesión de desarrollar software seguirá siendo poco más que amontonar bytes. Bueno, amontonar bytes y discutir sobre quién tiene el montón más bonito.

Addendum

Añado aquí algún detalle más que quizá me quedó hacer más claro y más patente en lo escrito ahí arriba.

Está claro que hay diferentes graduaciones. Sé, no lo dudo, que hay ocasiones en que dos soluciones pueden ser aproximadamente “igual de buenas”. Pero creo también que esto ocurre bastante menos que lo frecuentemente que usamos esa excusa. Y ahí está una parte del problema: Ese es justo el camino por el que se introduce ese relativismo: Damos demasiada importancia a esos (en mi opinión pocos) casos, frente a los casos en que sí que podríamos comparar más objetivamente.

Por otra parte, creo que si muchas veces nos resulta difícil comparar es solo porque no hemos establecido nosotros mismos unos criterios de valoración. Demasiadas veces no tenemos clara qué opción es mejor solo porque no nos hemos parado a establecer qué es lo que significa “mejor” para nosotros. Es precisamente aquí donde creo que ese “poquito de ingeniería” más podría ayudar, donde las metodologías y herramientas de la ingeniería pueden ayudarnos a tener unos resultados más sólidos, más consistentes. Establecimiento de criterios, de formas de evaluación, estimaciones de costes, economías, etc, son conceptos que no son ni complicados ni difíciles de aplicar. Y estoy convencido de que pueden producir interesantes beneficios.

Añado también que creo que muchos de esos pocos casos en los que es difícil comparar, suelen ser los que menos importancia tiene hacerlo. De nuevo, es un tema de criterios y valores. El simple hecho de establecer criterios y valores, nos deja ver, fácilmente esos casos en que dos soluciones son aproximadamente igual de buenas. Y entonces, en esos casos, la decisión es evidente: o bien la más “barata” 7) o bien simplemente cualquiera de las dos. Pero entonces decidimos desapasionadamente, porque somos conscientes de que ninguna es mejor.

1)
ya, siempre hay casos especiales; luego hablaré de eso
2)
Sí, el enlace va a la película, no a la historia “real”, pero es más divertido así
3)
no voy a suponer carencias a nadie para no herir susceptibilidades :p
4)
Ay, todo me entristece últimamente xD
5)
O por lo menos eso me gustaría pensar.
6)
Y a todo el que quiera mirar, que para eso parece que sirven los blogs y artículos en Medium y los enlaces en Twitter y patrocinar eventos: para congratularnos de lo bonito que parece todo.
7)
También tenemos que establecer cuáles son nuestros costes y retornos.