El código científico malo supera al código que sigue las «mejores prácticas» (2014)
La investigación científica suele depender de scripts rápidos y puntuales escritos por expertos del dominio, mientras que los desarrolladores profesionales tienden a introducir «mejores prácticas» y abstracciones más pesadas, incluso en bases de código pequeñas y experimentales. Los comentaristas discuten qué es peor: el código científico frágil y sin documentación que socava la reproducibilidad, o los sistemas sobreingenierizados que son difíciles de entender, modificar y adaptar a preguntas de investigación cambiantes. Muchos concluyen que el verdadero problema son los incentivos y el contexto, y piden un equilibrio entre simplicidad y disciplina de ingeniería, además de ingenieros de software de investigación dedicados a cerrar la brecha.
Reacción general al artículo
- Muchos ven la publicación como una diatriba o un hombre de paja: contrapone el «código malo de científicos» frente al «código malo de programadores» usando ejemplos extremos.
- Otros dicen que resuena con mucha fuerza, especialmente la crítica a la sobreingeniería y a las «mejores prácticas» aplicadas como culto de cargo.
- Varios sostienen que el verdadero objetivo debería ser el «programador malo» (a menudo juniors o adeptos al culto de cargo de patrones), no la ingeniería de software en su conjunto.
Científicos vs. ingenieros de software
- La opinión común: los científicos suelen infraingenierizar (código desordenado, improvisado, scripts de un solo uso); los ingenieros de software suelen sobreingenierizar (capas de abstracción, herencia, patrones «enterprise»).
- Algunos argumentan que los científicos a menudo son más inteligentes en su dominio y pueden ser más eficaces para herramientas puntuales; otros responden que la inteligencia en el dominio no sustituye la habilidad en software.
- Varios comentaristas señalan que, en la práctica, gran parte del código científico tiene errores, no es reproducible y muchas veces ni siquiera funciona un año después.
Sobreingeniería, «mejores prácticas» y complejidad
- Fuerte crítica a:
- Abstracción excesiva (herencia profunda, sistemas de plugins, muchos archivos pequeños, capas de indirección).
- Diseño guiado por patrones («Clean Code» tomado literalmente, microfunciones, grafos de módulos desmesurados).
- Java empresarial / OOP pesada como fuentes históricas de complejidad innecesaria.
- Contraargumento: estos son abusos de las mejores prácticas, no las prácticas en sí; la buena ingeniería busca el diseño más simple que permita cambios a largo plazo.
Patologías en el código científico
- Problemas recurrentes: sin pruebas, sin control de versiones, rutas y datos codificados a mano, pasos de compilación sin documentar, mal uso del hardware (por ejemplo, cargar todos los datos en RAM).
- La reproducibilidad se considera ampliamente deficiente; algunos dicen que esto subyace a la crisis de replicación.
- Otros señalan que las expectativas difieren: históricamente, la academia aceptaba esfuerzos de reproducibilidad «manuales», no reejecuciones con un solo botón.
Ejemplo del modelo de COVID del Imperial College
- Varios mensajes usan esto como advertencia: código científico grande y de larga vida con errores graves (no determinismo, problemas de memoria, diseño frágil) supuestamente produjo resultados engañosos relevantes para políticas públicas.
- Se cita como evidencia de que el código de investigación «rápido y sucio» puede ser peligroso cuando se reutiliza para decisiones del mundo real.
Colaboración y roles
- Muchos abogan por «ingenieros de software de investigación» dedicados a tender puentes entre la experiencia de dominio y la disciplina de ingeniería.
- Se considera ideal emparejar expertos de dominio con desarrolladores centrados en mantenibilidad, pero está infradotado; los incentivos en la academia priorizan los artículos por encima del software robusto.