¿Y si nos cuestionáramos todo lo que creemos saber sobre cómo debemos programar?
14 dic 2021 . Actualizado a las 14:26 h.Según la Wikipedia, la ingeniería es una disciplina que usa el método científico para «diseñar y construir y perfeccionar máquinas, sistemas y procesos» en vez de para descubrir cómo funciona el Universo.
El método científico se basa en la observación, experimentación y medición de datos para validar una hipótesis. Sin embargo, apenas hacemos experimentos que nos ayuden a entender cómo construimos software y validen nuestras creencias sobre cómo deberíamos hacerlo.
El pasado julio, Greg Wilson —doctor en Informática y desarrollador, con experiencia en campos como la visualización de datos o seguridad informática— repasó algunos de esos estudios y las conclusiones de los mismos, que revelan sorprendentes hallazgos... y pueden acabar con algunos mitos intocables del desarrollo de software.
Sorprendentemente, la charla de Wilson apenas ha tenido eco en la Comunidad técnica. Quizás porque nos obliga a ponernos frente al espejo y descubrir que no nos gusta lo que vemos. Quizás por eso también, este es un momento tan bueno o malo como cualquier otro para repasar algunos de los más polémicos.
«Usando TDD se escribe código de más calidad»
Uno de los pilares de la profesión es que usar la técnica de Test-Driven Development o TDD nos hace programar más calidad. Con menos fallos y, por tanto, con mayor productividad a la larga.
Cuando alguien se ha atrevido a poner en duda esta afirmación siempre se ha contrargumentado que si no se consigue es por falta de práctica con la misma. No se cuestiona la técnica sino la pericia del que la emplea. Sin embargo, cuando se ha intentado probar científicamente esa supuesta mejora, no se ha obtenido ninguna evidencia de que escribir tests antes del código nos haga más productivos que escribirlos después.
Un estudio posterior sobre el trabajo de 39 desarrolladores en proyectos reales tampoco pudo demostrar que hacer testing antes o después de escribir código tenga un impacto relevante en la calidad del mismo. Sin embargo, sí se constató que había una correlación entre la duración del ciclo codificación-testing y la calidad del código producido.
Cuanto más pequeño era este ciclo —por ejemplo, una hora programando y una hora haciendo testing en vez de un día de programando y otro probando— la productividad es mucho mayor. Una de las hipótesis barajadas es que como TDD también fomenta los baby-steps o ciclos cortos de codificación-prueba se habría otorgado a TDD un supuesto beneficio que, en realidad, correspondía al empleo de ciclos de desarrollo más cortos.
Este estudio es un ejemplo de cómo podemos dar con la respuesta correcta por las razones incorrectas. El empleo del método científico nos ayudaría a identificar lo que realmente nos beneficia.
«Algunos lenguajes de programación son mejores que otros»
Pues depende. Dentro de los lenguajes de propósito general, uno puede ser más eficaz que otro para realizar una tarea concreta, pero a lo largo de mi carrera profesional, apenas he conocido a un puñado de personas que conozcan dos lenguajes de programación con suficiente profundidad como para poder hacer una comparación seria y desapasionada de los mismos.
Las apuestas a favor de un lenguaje u otro suelen estar basadas más en opiniones y sensaciones que en información y experimentación, pero lo que Andreas Stefik si pudo demostrar fue que, para aprender a programar, algunos lenguajes son más eficaces que otros.
Comparó tres lenguajes: Perl, Quorum —el lenguaje que su equipo estaba diseñando— y Randomo, un tercer lenguaje cuya sintaxis generaron de forma aleatoria. Sorprendentemente, para los novatos era igual de complicado entender la sintaxis de Perl que una generada aleatoriamente, tirando dados de Dungeons and Dragons.
Mucha gente se echó las manos a la cabeza con el estudio de Stefik así que este hizo un segundo para corroborar su hipótesis, con más participantes y diversas estrategias de evaluación. Averiguó que todos los lenguajes de la familia C (Perl, Java, C++...) son tan complicados para leer, aprender y entender para un novato como un lenguaje diseñado aleatoriamente.
Ruby y Python, sin embargo, son bastante más fáciles de dominar y Quorum —el lenguaje que estaban diseñando— aun más, porque hicieron AB testing de cada funcionalidad antes de añadirla al lenguaje.
«El error más frecuente»
Otro estudio muy interesante fue el realizado a partir de 37 millones de compilaciones registradas en el IDE que usan para aprender a programar los estudiantes universitarios de Inglaterra y Gales.
Cuando se preguntó a los profesores cuales eran los errores más frecuentes que cometían los estudiantes, no solo no se pusieron de acuerdo entre sí sino que sus impresiones diferían —con mucho— de la realidad.
Sufrían un sesgo del superviviente de libro. El problema es que el código que revisaban era solo el que los estudiantes consideraban que funcionaba «suficiente bien» como para enviar y ser evaluado, no todas las versiones anteriores. Analizando las mismas, se pudo detectar no solo cuales son los errores más comunes (paréntesis no coincidentes, invocar métodos con los argumentos incorrectos y cerrar métodos que devuelven algo sin hacer return) sino, también, los que mas se tardan en arreglar.
Wilson considera que estos datos podrían usarse para diseñar la nueva generación de lenguajes de programación, incorporando mecanismos para evitar estos problemas, pero Bonilla cree que los mismos deberían tenerse en cuenta de forma inmediata para reformular las trayectorias curriculares de bootcamps y escuelas.
A lo largo de la charla, se desmontan más mitos sobre métricas de código, el «gen de la programación», los tenxer —programadores mitológicos que multiplican por 10 la productividad habitual— o el beneficio del pair programming; y se sugiere que los iniciados en Data Science deberían intentar replicar los resultados de algunos de los estudios más sencillos, usando como data sets los innumerables repositorios de código abierto que están disponibles gracias al auge del open source. No olvidemos que uno de los principios del método científico es la refutabilidad, la posibilidad de someter una teoría o hipótesis previamente validada a potenciales pruebas que la contradigan.
Pero más allá de refutar una teoría u otra, la charla de Wilson nos debería hacer reflexionar sobre la progresiva fanatización y radicalización de la Informática, una supuesta rama técnica donde —sin embargo— parece que cada vez cabe menos el pensamiento crítico. Cuando alguna voz discordante pone en duda la doctrina general, la laminamos sin considerar ni por un momento la validez de sus argumentos ni sentirnos obligados a justificar los nuestros.
Los colegios profesionales de Informática están luchando para que la Informática se equipare legalmente a otros ingenierías, pero a lo mejor también deberían preocuparse por asegurarse de que continua siéndolo. Quizás deberíamos enseñar a aplicar el método científico a nuestros estudiantes antes de que se gradúen y estén demasiado ocupados para aprenderlo.
Manejamos mejor que nadie la materia prima más valiosa y peligrosa del mundo, la información. Nos ganamos la vida construyendo herramientas para que otros puedan recogerla y gestionarla. Quizás, el mayor regalo que le podríamos hacer a nuestra profesión es construirlas también para nosotros mismos.
El turismo es un nicho en el que somos punteros
Lodgify es una startup fundada en Barcelona en 2012 que desarrolla un SaaS para gestionar alquileres vacacionales. Su misión es permitir que cualquiera pueda entrar en el sector del alojamiento turístico, arrancar su negocio y hacerlo crecer a través de la tecnología, siendo independientes de a las grandes corporaciones que dominan el mercado hoy en día.
Están buscando un/a Developer Web que tenga experiencia con .NET Core y MVC; y que pueda trabajar con JavaScript, HTML y CSS sin que se le ponga el pelo verde.
Además de un salario entre 40 y 50.000€, dependiendo de tus conocimientos y experiencia, ofrecen beneficios corporativos como ayuda para mudarte a Barcelona (si quieres trabajar en la oficina de vez en cuando), la posibilidad de trabajar en remoto al 100%, seguro médico privado y 25 días de vacaciones.
Parece una buena oportunidad para desarrolladores que quieran trabajar en una startup de producto con un ambiente internacional.
Este texto se publicó originalmente en la Bonilista, la lista de correo de noticias tecnológicas relevantes para personas importantes. Si desea suscribirse y leerlo antes que nadie, puede hacerlo aquí ¡es bastante gratis!