Tabla de contenidos
Luis Fernández es un auténtico fenómeno de la ingeniería de software. Ha hecho de todo: investigar, crear una start-up tecnológica, enseñar a estudiantes universitarios, formar a empresas e, incluso, reencauzar proyectos de software de grandes compañías.
Este ingeniero de software se expresa con claridad y con argumentos. En esta entrevista reflexiona sobre cómo se enseña Informática en España. Su visión es crítica. Considera que las nuevas generaciones de ingenieros informáticos salen de la universidad sin los conocimientos necesarios y suficientes. Y, lo que es peor, sin la actitud con la que los buenos desarrolladores se deberían meter en los proyectos.
Cultura de la excelencia en Omatech
Hace ya unos meses que Luis está mentorizando al equipo humano de Omatech para consolidar la cultura de la excelencia que ha inspirado siempre a esta agencia de proyectos digitales. Para saber cómo está yendo este proceso de mejora, hemos hablado con él. La conversación ha sido todo un placer, porque Luis huye de los clichés y cuenta las cosas como las piensa.
Reflexiones sobre el desarrollo de software
En esta entrevista, Luis hace interesantes reflexiones sobre quienes hacen código y sobre cómo lo hacen, y defiende que todo buen desarrollador debe tener una faceta de artista. «Cuando hablo de arte, me refiero a la creatividad, libertad y criterio para saltarte las reglas cuando el buen fin del proyecto lo requiera».
‘El Principito’ y el código perfecto
En la charla, echa mano de leyendas del desarrollo de software. Y, para definir qué es una obra maestra del código, recurre, como hacen otros ingenieros de software, a El principito. «Un diseñador», leemos en el libro de Antoine de Saint-Exupéry, «sabe que ha conseguido la perfección no cuando no hay nada más que añadir, sino cuando no hay nada que quitar». Trasladada esta idea al mundo del software, la lección es que «no sobre nada» al hacer desarrollo de software.
Luis Fernández es doctor en Inteligencia Artificial por la Universidad Politécnica de Madrid e Ingeniero en Informática.
Cambio cultural en el desarrollo de software
¿Qué historia hay detrás de la formación que haces en Omatech?
Cesc Delgado me llamó para hacer un curso. Para ponernos en marcha, evaluamos el mejor enfoque. En esa conversación, surgió un buen feeling y la conciencia de que hacía falta algo diferente al curso tradicional.
Con el curso de 30 horas, enseñas, te vas y los desarrolladores ponen en práctica aquello de lo que se acuerdan, y poco más. Así que convenimos un reto que a mi me pareció muy interesante: quedarme con ellos, por decirlo de algún modo. El objetivo era ayudar a un cambio cultural en el ámbito del desarrollo de software.
La idea era acompañar a toda la empresa para emprender cambios de abajo a arriba. Además, en cualquier organización también es muy importante insistir en los rudimentos. Ese propósito es sobre todo relevante si se tiene en cuenta que hay planes de estudios que negligen las asignaturas básicas. En la universidad hay una buena parte de contenidos que no vas a ver nunca en tu vida profesional.
Como rutina, nos reunimos un día a la semana, y nos miramos el código que se ha escrito durante los últimos siete días. Estoy mentorizando con una perspectiva pragmática y constructiva.
Omatech, trabajo en equipo de los desarrolladores
¿Cómo está siendo el trabajo de ‘mentorización’ con los desarrolladores de Omatech?
Lo primero que me llamó la atención cuando comenzamos en septiembre de 2021 es que los jefes están con el resto de desarrolladores. Es decir, que los responsables se remangan y se exponen delante de todos en las reuniones del equipo de desarrollo al completo. Así se fomenta más fácilmente el espíritu de grupo y la comunicación. Con esta forma de trabajar horizontal, se fomenta el trabajo en equipo.
Por lo que dices, os fijáis en ejemplos concretos.
Cuando nos sentamos, nos ponemos el mono de trabajo. «Venga, enséñame este commit«, le pido a un miembro del equipo. Todos vemos lo que se ha hecho. Si se ha hecho una virguería, todos podemos apreciar la alta calidad del código, y se consolida una cultura de excelencia, de hacer las cosas muy bien.
Semana a semana, ¿has notado cambios en la forma de funcionar del equipo?
Ahora hablan más, y veo cómo se preguntan más unos a otros en estas sesiones de mejora. No hay objeción a resolver los problemas, no solo con herramientas, sino desde la base.
Programación informática con perspectiva
Los equipos de desarrollo de software, por tanto, ¿deben tomar perspectiva a la hora de avanzar en sus proyectos?
Si buscamos una metáfora, lo que hace falta es limpiar la bayeta cada semana. No la puedes pasar si está llena de bacterias. Te ofrezco otro símil: si utilizas el hacha cada día, pues un día a la semana deberías tomarte una pausa y dedicarte a afilarla. Tiene que haber un aprendizaje continuo y progresivo. Sin embargo, tengo la nítida sensación de que la mayoría de programadores no tienen ni la sutileza ni las ganas de llevar la teoría a la práctica.
La ‘gran bola de barro’
¿Qué pasa si no haces ese esfuerzo de revisión y de poner tu trabajo en perspectiva?
En el mundo del software tenemos el concepto de big ball of mud, o gran bola de barro. Con este símil nos referimos a un sistema de software al que le falta planificación, racionalidad y arquitectura.
Yo hablaría de una bola de porquería que coge inercia, cae por la ladera, y no hay quien la detenga.
¿Qué ocurre cuando el código de un proyecto de software es un auténtico caos?
Hay que rehacer el proyecto entero con técnicas de refactoring. Puede pasar en las mejores casas. Así, hace tiempo ayudé a rehacer un proyecto ya muy avanzado de una multinacional de grandes superficies. Se tiró entero todo el código que se había hecho.
¿Qué riesgo hay con proyectos digitales de gran envergadura y complejidad?
El principal riesgo es que el proyecto se te vaya de las manos. Para que los proyectos sean un éxito, en tiempo y en prestaciones, debe haber un buen trabajo de planificación.
La frustración del programador de software
¿Cuál es la mejor forma de aprender código? ¿Qué hay que tener en cuenta?
Ahora se enseña código muy mal, muy rápido y a partir de la dictadura de las modas. Los planes de estudios están hinchados, con la inclusión de Inteligencia Artificial, Big Data y otros conocimientos que están ahí para agradar a los alumnos. Esta forma de hacer las cosas causa frustración, porque muchos desarrolladores no están preparados. El 80% de los programadores sienten ira o frustración a diario en su trabajo.
«Nadie se forma en un lenguaje de programación en dos meses»
Eres crítico con la formación universitaria de los estudios de informática. ¿Cómo se podría mejorar?
Los planes de estudios son demasiado ambiciosos y obvian muchos conceptos básicos. Quien mucho abarca, poco aprieta. ¿Cómo puede ser que los estudiantes tengan un porcentaje relevante en la decisión de los contenidos de sus estudios? No creo que sea una buena idea que el estudiante decida sobre lo que debe aprender cuando, precisamente, está aprendiendo.
Además, necesitamos más prácticas en los planes de estudios. Y es que los estudiantes salen de la universidad sin haber hecho un proyecto entero.
Al margen de cómo están planteados los estudios universitarios, ¿qué errores hay en la formación de programadores?
Es fácil perder el Norte. Dice Bjarne Stroustrup [creador del lenguaje C++] que, para pasar de C a C++, hace falta seis meses de práctica. No te puedes formar en tan solo dos meses. Insisto, es muy importante que un desarrollador tenga una base sólida, porque si no la tienes, es fácil que vuelques.
Cómo debe ser un buen programador de software
¿Qué características debe tener un buen programador?
Quien mejor lo expresó fue Larry Wall, el dictador benevolente vitalicio de la comunidad de Perl, un lenguaje que tuvo su impacto. Este señor dijo que un buen programador debe ser perezoso, impaciente y arrogante. Es muy chocante, pero tiene razón.
Por perezoso, alude a la calidad. No podemos escribir un océano de líneas de código para que funcione, cuando eso podía haber sido escrito de una manera muchísimo más reducida y sin ese gasto de energía. De este modo, no hay que tirarse a escribir líneas y líneas. Por el contrario, hay que pensarse muy bien cada línea.
Cuando dice impaciente, se refiere a cubrir las necesidades, incluso anticiparse a las necesidades que se le vaya a requerir al software. ¡Hay que obtener resultados!
Finalmente, por arrogante entiende un orgullo excesivo, de forma que nadie pueda hablar mal de tu código. «Lo que está hecho, está muy justificado. ¡Sé lo que estoy haciendo!» Con estos tres criterios, tenemos mucho hecho. Sin embargo, yo añadiría otros atributos: mucha autoexigencia, mucha autocrítica, mucha reflexión… Y estas son precisamente características que no abundan hoy en día.
Del programador al ‘ingeniero de componentes’
¿Están cambiando los requisitos de este buen programador por la evolución de la naturaleza de los proyectos que se emprenden? Lo decimos porque ahora hay más integraciones, más interacciones, más necesidad de generar y explotar ‘Big Data’, más complejidad del mundo empresarial…
Sí, los requisitos están cambiando. Cuando yo era joven, te preguntaban: «Bueno, ¿tú qué? ¿C o COBOL?». Daban a entender que con un lenguaje de programación, ya tenías profesión para toda la vida. Ya se ha visto que esto no es así. De hecho, hoy en día ya no se habla de programador, sino de desarrollador.
Con esta adaptación terminológica se está diciendo que no solo vale con programar en más de un lenguaje, con un poquito de cultura y con varios paradigmas. Además, también te piden diseño y pruebas cuando haces inmersión en un proceso de desarrollo de software. Ahora, lo que vas a programar va a ir cambiando iterativamente. Ya no es como antes: «Oye, que hay que programar esto». Para ilustrar esta idea, puedo decir que en septiembre me llegaron varios emails en que me hablaban de la crisis de desarrolladores de calidad. Esto ya se sabía, pero ahora está encima del tapete.
El ‘programador 10’
¿Crisis de desarrolladores de calidad? ¿Qué es un desarrollador de software de calidad?
Lo que Grady Booch, el ingeniero de software, llamaba el programador 10, es un programador que escribe 10 veces más rápido, 10 veces mejor código que 10 programadores juntos que son mediocres. Ahora a los programadores se les exige muchos conocimientos más allá de un lenguaje, de una librería, de un framework… En algunas metodologías, ya no se les llama programadores, sino que se les llama ingenieros de componentes.
Errores en desarrollo de software
¿Cuáles son los principales errores cuando escribimos código?
No es por disculpar a los programadores como colectivo, pero perteneciendo yo al sistema educativo, creo que la gran mayoría de errores que cometen los programadores es por culpa de la universidad. Como ya he dicho, el sistema universitario, que es el sistema más profesional, tiene planes de estudios muy ambiciosos. Así, en las asignaturas ves lo último que está de moda. El reverso de eso es que se están olvidando cosas básicas.
Y ya no te quiero ni contar en los estudios de grado medio o en los famosos bootcamps: «En dos meses te prometo ser un profesional de este lenguaje». Esto va creando unas lagunas enormes. De modo que, cuando el estudiante tiene que hacer una cosa un poco diferente a cómo se lo enseñaron, está perdido. Si, en estos tiempos de postmodernidad, a todo esto le sumas la superficialidad, un pragmatismo mal entendido y una ignorancia atrevida, te encuentras soluciones que son absurdas. Y, encima, se defienden con vehemencia. La gente confunde la crítica a un código o a un diseño con la crítica personal. Yo, en tono coloquial, hablo de pormihuevismo.
La crítica del ingeniero de software Dijkstra al sistema educativo
Eres un experto en software con espíritu crítico. ¿Te consideras de los pocos que dicen que ‘el rey va desnudo’?
Creo en la mejora continua. Para ello, es necesaria una perspectiva crítica. Y la verdad es que hay muchos más docentes que consideran que el sistema educativo tiene defectos y que hay que mejorarlo. Incluso nos viene bien una cita de Edsger Dijkstra…
¿Qué dice Dijkstra que, recordemos, es ganador del Premio Turing?
Te leo la frase literal: «A las universidades les seguirá faltando el coraje de enseñar ciencia dura, seguirán orientando mal a los estudiantes, y cada nuevo escalón de infantilización del currículum será ensalzado como progreso educativo».
La creatividad en el desarrollo de software
¿Qué importancia tiene la creatividad y comprender cómo piensa el público de un proyecto digital a la hora de escribir código?
En 1968, el año en que yo nací, salió el primer volumen del Arte de programar computadoras, de Donald Knuth. Bien, más que libro, es una enciclopedia de siete volúmenes. Es una obra tremenda, con un rigor y una seriedad impresionantes. Pero ese mismo año se reunió la OTAN, por decirlo de alguna manera, porque Edsger Dijkstra ya había hablado de la crisis del software en su ponencia de El programador humilde. [Fue la conferencia que dio al recibir el Premio Turing de 1972]. Ante esa crisis, se reunieron los mejores, y de ahí salió la ingeniería del software. «Vamos a traer disciplina y ciertas pautas de cómo hacer las cosas». Así que parecía que la idea del arte de programar se estaba disipando…
¿La disciplina anulaba el arte de programar?
Yo creo que no, que hay o que debe haber un equilibro entre disciplina y arte. Lo que hay son muchos principios que saber, muchos conceptos que manejar… Ahora bien, cuando estás en pleno desarrollo, el arte consiste en saber responder las siguientes preguntas. ¿Qué principios son los que aplico aquí ahora? ¿Y qué principio me salto porque considero que no me hace ningún daño en este punto? Un buen ingeniero sabe qué principios de diseño aplica y deja de aplicar en cada momento. Y cuando hablo de principios de diseño no me refiero a los principios SOLID, porque eso es una bagatela del agilismo flácido. Me refiero a 40 principios, 60 principios… La verdad es que no los he contado.
Escribir código de programación es divertido
Por tanto, ¿el desarrollador de software puede y debe ser creativo?
Hay disciplina, hay rigor, pero hacer código es muy divertido. Cada problema requiere una solución para llegar a un código mínimo. El ingeniero de software Kent Beck, que ha tratado mucho el concepto de código mínimo, dice que él no es un gran programador, sino muy disciplinado. Para hablar del arte en programación tomo la cita del libro El principito: «Llegar al punto en que no sobra nada». Esa es la obra maestra.
La polea de Arquímedes, la informática y el próximo gran invento
Hoy todo es código, todo es más ‘tech’. ¿Qué oportunidades y amenazas plantea la omnipresencia de apps y de software en nuestras vidas?
Tengo una postura tranquila. La informática no tiene ni 100 años, y ha deslumbrado a la humanidad. Sin embargo, a lo largo de la historia, también alucinaron con las poleas. Cuando Arquímedes levantó un barco moviendo una polea, dejó boquiabiertos a todos. «Esto es magia, esto es una locura. ¿Pero a dónde vamos a llegar?». Pero es que lo mismo pasó con la energía eléctrica. Y luego cada nueva invención va ocupando su lugar, porque siempre habrá algo que deslumbrará aún más al ser humano.
‘I, robot’, de Asimov: «De momento, no»
¿Qué pasa con las visiones más apocalípticas, con la distopía de ‘I, robot’, de Asimov?
¿El software podrá acabar dominando la humanidad? No lo creo. Se habla mucho de inteligencia artificial, pero tengo entendido que no hay ni un solo software que haya superado la prueba de inteligencia de Turing. Lo que hay es software de altísimas capacidades, que podemos llamar de inteligencia artificial porque es que parece inteligente. Eso no niega la posibilidad de que algún sociópata use el software, que no deja de ser un instrumento, para fastidiar a millones.
El niño que disfrutaba con las ‘mates’, pero que no quería enseñar
¿Por qué convertiste la Informática en tu profesión?
Cuando tenía 16 años, yo no encajaba en el colegio de curas. Los profesores no incentivaban precisamente el talento. Las matemáticas me atraían, pero yo no quería enseñar a críos. Así que me vendieron la informática como una ciencia parecida a las matemáticas, aunque luego descubrí que no había tanto parecido. Acabé la carrera con buenas notas, y lo primero que me proponen es ser profesor. «¡Si yo precisamente he estudiado esto para no ser profesor!», dije.
¿Quién te inspiró más a dedicarte a la Informática?
Mi hermana Lola había estudiado Informática, y fue ella la que me dijo: «Hazlo, estos estudios son para ti». En casa nos gustaba la tecnología. Mi padre, inspector de Hacienda, que había cursado Derecho y Económicas, empezó a estudiar Cibernética.
¿Cuándo fue la primera vez que usaste un ordenador?
Cuando yo era pequeño, llegó un Spectrum a casa. Acabé programando algo en Basic. Y también jugaba, claro.
La informática, una ciencia inmediata
Tenías claro que no eras de Letras…
Ahora me gusta leer sobre Historia y Filosofía. Pero cuando era un adolescente, entendí que en Letras tenías que estar leyendo y aprendiendo durante años antes de destacar de forma profesional. La Informática la interpretaba como una ciencia inmediata, útil y operativa.
No te veías como profesor. Sin embargo, finalmente te acabaste dedicando a la docencia. ¿Qué te hizo cambiar de opinión?
Como he explicado, me propusieron ser profe. Yo me dije: «Mientras doy clases, acabo mis estudios superiores —entonces era técnico— y me voy al mundo de la empresa. ¡Pero me acabé enamorando de la enseñanza!»
Has formado a muchos estudiantes de Informática. Más allá de los conocimientos técnicos, ¿les transmites valores o principios?
Para mi siempre ha sido importante la coherencia. Pues bien, con los lenguajes de programación, hay modas. Ahora está de moda Python. Antes lo estaba Ruby. Yo advertía mucho ruido, porque con cada lenguaje nuevo que aparecía, allá iban todos a aprenderlo. Cuando yo me adentro en un lenguaje, lo quiero aprender bien.
Las modas en el desarrollo de software
Siempre habrá modas, ¿no?
Ahora, por ejemplo, tenemos la moda de la estadística aplicada a la informática, pero le llaman Big Data… ¡Mola más!
‘Big Data’, que dicen que es el ‘petróleo’ del Siglo XXI…
Yo hablaría más bien de boom. La obtención de datos y su análisis hace ya mucho que existen. Lo llamábamos minería de datos. Lo que ha pasado es que en los últimos años se ha acuñado el término Big Data, que tiene más sex appeal y que ayuda a vender mejor el concepto.
También pienso en el agilismo. El agilismo, que hace más de 20 años que se aplica en la ingeniería de software, es la antítesis del desarrollo en cascada, más rígido. ¡La ley del péndulo!
Crítica al agilismo
¿La ley del péndulo? ¿Qué excesos identificas en el agilismo?
El agilismo lleva al extremo la respuesta al método en cascada. Con el desarrollo de software en cascada construyes un software como construyes un puente. Sin embargo, la ingeniería de software no es la ingeniería de obras públicas. Así, cuando estás en pleno proceso de construcción de un puente, no puedes decir: «Oye, espera, que hay que darle más altura». Y con un software, en cambio, sí que puedes hacer ajustes.
El agilismo, que cuenta con un manifiesto muy romántico fechado en 2001, aboga por documentación cero y análisis cero. La parte negativa es que se desentiende de cosas buenas de las metodologías anteriores, como la del desarrollo en cascada. En los últimos años, varios autores del agilismo han renegado. El término agilismo flácido resume esa crítica. Lo acuñó Martin Fowler, uno de los pioneros del agilismo que ahora no quiere saber nada del sistema. Lo bueno es que ahora, por fin, empezamos a encontrar un equilibrio.
Una empresa tecnológica en el sector deportivo
Fuiste uno de los fundadores de una ‘start-up’ de software ligada a la Universidad Politécnica de Madrid.
La idea era que el software asistiese a las personas que van a practicar deporte. Instalamos tótems con pantalla táctil en 20 gimnasios. La máquina te decía qué ejercicios tenías que hacer. Además, también desarrollamos una App para uso en dispositivos móviles. Llegamos a tener 25 trabajadores, pero quizá nos faltó conocimiento empresarial.
¿Qué sensación te dejó esta experiencia emprendedora?
Fue un aprendizaje muy valioso. Al embarcarme en este proyecto, fui muy crítico conmigo mismo. ¿Enseño todo lo que hace falta en el mundo real? Por fin podía dar una respuesta aún más completa y desde la experiencia a esa pregunta.
En todo caso, a mi me gusta ser profesor universitario y enseñar a las empresas a hacer las cosas bien. Mi objetivo es ayudarles a dejar de trabajar a pico y pala.
Programar mejor, con más calidad y con más humanidad
En tu trabajo, ¿qué te da más satisfacción?
Para mi la medalla que tiene más valor es ayudar a otras personas a programar mejor, con más calidad, con más resultados y con más humanidad. Otros disfrutarán siendo catedráticos y con proyectos de investigación. Yo solo sé disfrutar a mi manera.
Además de dar clases en la universidad, también enseñas a través de una plataforma especializada…
Sí, imparto un master de programación y diseño de software a través de la plataforma EscuelaIT.
¿Qué aficiones tienes?
Me apasiona viajar. Además, en los últimos años he redescubierto la literatura y la historia. Por tanto, no solo leo código y papers sobre informática. Además, también me gusta el formato documental para aprender sobre matemáticas, historia, psicología… YouTube es para mi una ventana abierta al conocimiento, con gente que sabe mucho sobre lo que habla.
¿Podrías haber sido un profesor de Letras?
Pues, ¿por qué no? Son ciencias que no creo que estén tan alejadas. Libros como Crimen y castigo, de Dostoyevski, son legacy code.
TEXTO: Manel Torrejón (Blog de Omatech)
