¿Por qué tantos científicos talentosos escriben software horrible?

Voy a intentarlo. Esta es principalmente mi opinión personal basada en mi uso e implementación de software académico. Como muchos de los comentarios ya mencionados, no creo que el mal software sea específico o incluso más frecuente en la academia. Dicho esto, creo que hay algunas razones por las que ocurre que son específicas del campo.

El software no es una prioridad

En el ámbito académico, los indicadores clave de rendimiento tienen que ver con las publicaciones en papel. El software, aunque muy útil en mi opinión, tiene muy poco valor. La mayoría de las veces, las implementaciones de software son pistas secundarias o, en el mejor de los casos, pruebas de concepto que se utilizan para aumentar el número de citas (por supuesto, existen excepciones).

Como ingeniero de software, estoy seguro de que conoce el conocimiento, el tiempo y el esfuerzo necesarios para producir software de calidad. Dado el mantra de publicar o perecer en la academia, esta inversión de tiempo a menudo se dedica a escribir una nueva publicación. Es una consideración de riesgo-recompensa.

Mi punto de vista personal es que el software de calidad es muy importante. Por ejemplo, a menudo, el primer paso para comparar un nuevo algoritmo con el estado del arte anterior es volver a implementar el estado del arte debido a la falta de implementación. Obviamente, esto introduce un retraso de tiempo y puede causar una serie de errores. Dicho esto, creo que, en general, poco cambiará hasta que el software sea valorado por los indicadores de rendimiento de alguna manera.

Los investigadores no son programadores.

La mayoría de los investigadores tienen poca o ninguna experiencia en programación, aunque YMMV depende del campo. Creo que es justo decir que la mayoría de los investigadores aprendieron a programar por sí mismos cuando se enfrentaron a problemas donde lo necesitaban. El aprendizaje superficial de un idioma no suele ser el problema, pero se necesita más que un conocimiento superficial para producir software de calidad (elegir estructuras de datos, patrones de diseño, conocimiento profundo del idioma, ...). Este es un obstáculo para los programadores autodidactas sin experiencia en informática.

Otro problema al que se enfrentan los programadores menos experimentados es no darse cuenta de cuándo es necesaria la refactorización. Puede encontrar innumerables piezas de software mal estructurado. En la investigación, esta es una consecuencia natural de la implementación iterativa durante el diseño de un algoritmo que se convierte en una monstruosa pieza de software llena de hacks. Sin embargo, ese monstruo aún podría hacer lo que estaba destinado a hacer, si sabes exactamente cómo pedirlo amablemente. Para muchos investigadores ahí es donde termina la historia: obtenga los resultados y guarde a la bestia para siempre. A menudo se necesita una gran inversión de tiempo para lavar al monstruo antes de sacarlo a pasear en público. Esto no siempre vale la pena.

Tendencias en el aprendizaje automático

Mi campo es el aprendizaje automático, en el que cada vez se valora más el software. Los ejemplos de esta tendencia incluyen un repositorio de software en crecimiento y un documento de posición de algunos nombres importantes en el campo . Estoy muy contento con esta evolución, porque el software de calidad permite que el campo en su conjunto progrese más rápido y aumenta la reproducibilidad.

Un parche actual para el problema es poder publicar artículos sobre implementaciones de software revisadas por pares. Sé que esto es posible en el aprendizaje automático y las estadísticas . Dicho software suele ser de mayor calidad.

Además de la respuesta de @MarcClaesen, permítanme agregar el punto de vista de un químico.

• Soy un químico aficionado a la programación. Desde mi experiencia, esa es una especie rara. Tal vez menos raro en estos sitios. Aunque tal vez no sea más raro que un científico informático en un laboratorio de química que implementa buenas prácticas de laboratorio...

• Un punto importante a tener en cuenta es que los estudiantes (al menos los químicos) no tienen ninguna introducción a la programación de computadoras durante sus estudios . Es posible que deban recibir una introducción al uso de programas de hojas de cálculo y la búsqueda de bases de datos bibliográficas, pero eso es todo.
  Me encuentro con estudiantes que vienen a hacer sus prácticas de investigación y tesis en un subcampo que es pesado en el análisis de datos. Es extremadamente raro conocer a un estudiante que ya haya tenido algún tipo de experiencia en programación, aunque esta especialización "concentra" a estudiantes afines a las matemáticas. Todavía estoy buscando buenos cursos en la universidad donde podría enviarlos para obtener una introducción a la programación.
  Me gusta la carpintería de software.concepto. Pero tenga en cuenta que incluso no hay una introducción a las ideas y la mentalidad de la programación. De manera similar, los materiales de introducción que conozco realmente no comienzan donde los estudiantes deberían comenzar.
  (He buscado buenas presentaciones, porque tengo dificultades para recordar cómo era el mundo antes de comenzar a programar cuando era adolescente).

• Entonces, la mayoría de los científicos que no son de CS que conozco aprendieron a programar de una manera autodidacta y de nadar o ahogarse . Tenga en cuenta que la mayoría de los científicos naturales tienen una mentalidad que explorará un lenguaje de programación al igual que exploran el comportamiento de sustancias o instrumentos desconocidos.. Como los lenguajes de programación son deterministas, es comparablemente fácil obtener suficiente comprensión de esta manera para armar un script para calcular algo. (Recuerdo a un colega que tuvo su primer contacto con el lenguaje de programación en Matlab durante su tesis del Diplom. Un año después, "inventó" el concepto de funciones). Pero durante su tesis, no tiene tiempo para aprender buenas prácticas de programación. , incluso si quisieras. Y después se espera que trabajes y produzcas resultados. Aprender lenguajes de programación no es imposible, pero por lo general está bastante fuera del alcance esperado de lo que estás haciendo. El alcance esperado generalmente es que sepa cómo moverse lo suficiente como para realizar algunos cálculos.

• Un problema práctico relacionado que veo es que no hay programadores profesionales disponibles, por lo que no hay una buena tutoría práctica de programación para los estudiantes . Creo que esto sigue siendo un punto ciego en la organización de grupos de trabajo. Ninguno de los grupos en los que he estado trabajando hasta ahora tenía un programador profesional. Algunos grupos eran objetivamente demasiado pequeños para pagar uno (al menos no a menos que ese programador también hubiera sido bueno en el laboratorio de química/espectroscopia... - encontrar eso es incluso más difícil que encontrar un químico que haya aprendido algunos conceptos básicos de buenas prácticas de programación). ).

• La mayoría de los programas "monstruos" que conozco comenzaron su vida como un pequeño guión escrito por alguien que aprendió suficiente programación para armar las primeras líneas útiles de su vida. Durante los próximos 2-3 años (escenario habitual: estudios de doctorado) esto crece constantemente, y el tiempo siempre permitirá cambiar solo lo que se necesita en este momento. Como la gente es simpática, le dan el monstruo a otras personas que son aún menos programadoras. En el punto en el que uno diría que hay suficiente experiencia para dar un paso atrás y hacer una refactorización exhaustiva basada en la experiencia adquirida, se defiende el doctorado, el estudiante generalmente pasa a un trabajo completamente diferente y se abandona el proyecto de programación .

• Como científico, debo decir que los procesos de desarrollo de software a los que se refiere no son muy aplicables a gran parte de la programación científica que hago: requieren que ya tenga una idea de cómo se puede resolver el problema (¿Cómo se produce un entregable [o diseñe su arquitectura] si no tiene idea de cómo podría funcionar). A menudo, ni siquiera se conoce el resultado.
  Desde el punto de vista de la investigación básica, cuando sabes cómo funciona, has llegado al final de la investigación básica. Entonces comienza el desarrollo aplicado, y ahí veo cómo se pueden aplicar los procesos de desarrollo de software, pero esto está por definición fuera del alcance de los proyectos de investigación básica.
  La parte de investigación básica, OTOH, puede describirse como un enfoque de prueba y error para producir el primer vistazo básico a un entregable.
  Es posible que solo esté viendo la punta del iceberg del código científico donde estaría (habría estado) justificado hacer el esfuerzo de escribir código correctamente documentado con una interfaz definida, etc. (otras buenas prácticas como pruebas unitarias que preferiría ver ya con intentos muy tempranos...): posiblemente no vea las enormes cantidades de código que se producen para investigar ideas que luego resultan no funcionar tan bien y se abandonan.

• Hay una gran diferencia en la perspectiva de uso entre la mayoría de la programación científica que veo y un proyecto de software tradicional.. La mayor parte de esa programación ocurre en tesis de maestría o doctorado. El alcance de todo el asunto es bastante limitado. Normalmente será un proyecto unipersonal, porque una tesis por definición es un proyecto unipersonal. Por lo tanto, para el único desarrollador, el alcance del posible uso del software es, como máximo, de unos pocos años o de este único proyecto y, por lo general, también este único desarrollador será el único usuario. Esto es radicalmente diferente del desarrollo de software "normal". La perspectiva contrastante de la investigación básica es que incluso si el método se usa ampliamente y no resulta que la idea funcionó solo para el problema para el que fue inventado, lo siguiente que sucede es que alguien mejorará el algoritmo, posiblemente /generalmente conduce a una implementación totalmente diferente.
  No digo que esto no pueda o no deba hacerse con una implementación legible. Pero no es la situación lo que anima a esforzarse por aprender a escribir código legible.

• Una gran parte de la programación que hago consiste en generar análisis de datos adaptados a un experimento específico . Pragmáticamente, generalizo el código en paquetes reutilizables solo cuando sé desde el principio que lo necesitaré nuevamente o cuando realmente me encuentro con esta situación. Sin embargo, esto es sorprendentemente raro en comparación con, por ejemplo, lo que encontré cuando trabajaba como estudiante como desarrollador "normal" de una aplicación de base de datos. Sin embargo, en parte esto probablemente se deba a que para algunos proyectos en los que sé que el código se reutilizará, configuré un paquete/biblioteca desde el principio que desarrollo en paralelo a los análisis de datos en cuestión. Pero mi perspectiva sobre eso es completamente diferente del alcance de los estudiantes, ya que espero seguir usando este código base durante años.

• Una de las experiencias más bonitas y asombrosas (totalmente inesperadas) wrt. La programación científica que hice fue: presenté un trabajo y liberé la implementación del software en paralelo. Uno de los revisores preguntó cómo me aseguro de que los cálculos sean correctos, lo que me permitió responder que utilizo pruebas unitarias y que el paquete contiene aproximadamente el doble de código para las pruebas que para los cálculos. Esto fue inesperado porque ya es bastante inusual en mi campo publicar el código con el documento, pero no había visto antes ningún documento que explicara qué pruebas automáticas se proporcionan para la implementación, por lo que no esperaba que esta información pudiera hacerlo. en el papel real.
  ¡Tomo esto como una señal extremadamente prometedora!

• Otra señal muy prometedora es que cuando les explico a mis colaboradores* el concepto de sistemas de control de versiones, a muchos les gusta la idea y la describen como algo que pensaron que debería existir pero que no sabían que en realidad existe fuera del alcance del seguimiento de cambios de Word. (Aunque para el flujo de trabajo de investigación sigo pensando que el VCS que conozco (svn, git) funciona tan bien como para proyectos de codificación puros). Actualice
  unos años más tarde: hacer que colegas que no son programadores usen el control de versiones sigue siendo muy cuesta arriba discusión (también porque VCS que trata con archivos binarios no mejoró tan rápido como esperaba). En su mayoría retrocedí un paso y ahora usamos nextcloud para compartir datos, que si bien no proporciona un control de versión real, al menos facilita que todos hablen sobre el mismo estado de los datos/archivos.

* también los que no programan en absoluto y que introducen los datos medidos en el sistema, o que hacen, por ejemplo, la interpretación médica/biológica.

actualización: a partir de la experiencia que obtuve desde que escribí esa respuesta por primera vez, ahora pondría los aspectos organizativos mucho más arriba:

La mayor parte del tiempo he dejado la academia, trabajo como autónomo ahora, pero todavía tengo proyectos de investigación en los que soy subcontratista de instituciones de investigación (académicas). Para un determinado procedimiento de preprocesamiento que me encargaron proporcionar, encontré una negativa rotunda a pagar por "cosas innecesarias", como pruebas unitarias y encapsular el código de trabajo en una biblioteca/paquete con su propio espacio de nombres. El método es un procedimiento de análisis de datos, por lo que el tipo de error más importante son los errores en la lógica de programación (contra los cuales las pruebas unitarias pueden proporcionar un cierto nivel de protección). Es para ser utilizado en R, es decir, en escenarios de trabajo interactivo lo que implica un alto riesgo de desordenar el espacio de trabajo del usuario si la funcionalidad de terceros no está encapsulada en su propio espacio de nombres.
Esa negativa provino del nivel superior de gestión del instituto de investigación.

@gerrit comenta que la burocracia universitaria puede no permitir que un grupo tenga un programador profesional. Creo que esto es probablemente cierto como una realidad del día a día. Sin embargo, también creo que está relacionado con esta ceguera organizacional de la que estoy hablando aquí. Si la alta dirección en el mundo académico viera la importancia de utilizar técnicas de trabajo de última generación en el tratamiento de datos y el desarrollo de software, la administración universitaria probablemente también tendría una opinión diferente al respecto. Y si las propuestas de subvención incluyeran temas de administración de software y datos profesionales, las cosas también mejorarían en ese nivel. Creo que la academia se encuentra en un círculo vicioso aquí: todos, excepto los estudiantes, se consideran muy caros, por lo que las propuestas de proyectos no se atreven a incluir personal "técnico".
Y, por supuesto, la alta dirección puede estar convencida por sus colegas o por ejemplos de cuánto ayuda el tratamiento profesional de estos aspectos, pero mientras no estén convencidos, será extremadamente difícil encontrar dinero y permiso para probar si y cómo. mucho ayuda.

Hay algunas respuestas excelentes por ahí y me gustaría aportar mi opinión sobre el tema, ya que es un tema muy relevante en el que a menudo pienso o discuto con mis colegas. Inevitablemente habrá algunas superposiciones con partes de las respuestas existentes, solo espero poder dar una perspectiva ligeramente diferente en esos casos.

He hecho matemáticas aplicadas como mi especialización e hice mi maestría en modelado biológico y médico (lo que sea que eso signifique). Estoy a medio tiempo de mis estudios de doctorado en bioinformática y biología de sistemas . Trabajo casi exclusivamente en silico y he llegado a engendrar muchas de esas piezas de software monstruosas, feas y tristes.

En primer lugar, creo que está cometiendo un pequeño pero importante error al formular su pregunta. Tu dices:

"¿ Por qué tantos científicos talentosos escriben software horrible? "

en cambio, sugeriría

"¿ Por qué el software escrito por científicos talentosos termina siendo horrible? "

La diferencia es sutil pero esencial para el resto de mi respuesta. Después de todo, no es como si los científicos se reunieran alrededor de una mesa y decidieran escribir un software horrible.

Muchos científicos que escriben código no están capacitados para escribir software.

Hay una gran diferencia entre saber programar y saber escribir software . Hice casi tantos cursos en el departamento de informática como en matemáticas, durante mi licenciatura y maestría, por lo que me sentí bastante seguro con mis habilidades de programación. Eso fue hasta que me enfrenté a preguntas como empaquetado, gestión de dependencias, ciclos de vida, licencias, etc. Ninguno de estos estaba remotamente dentro del plan de estudios durante mis estudios. No sé si aquellos que hacen informática como estudiantes universitarios aprenden estos conceptos, pero estoy seguro de que nunca necesité hacerlo hasta que de repente tuve que conocerlos.

Los jefes/supervisores de muchos científicos que escriben código no están capacitados para escribir software

No solo necesita aprender un montón de cosas nuevas, sino que imagine que no puede explicar por qué es importante que aprenda esas cosas para su jefe. Tengo este problema con bastante frecuencia, ya que escribir código a menudo se considera comparable a hacer trabajo de laboratorio en nuestro departamento. La gente piensa que escribir código sucede solo y preferiblemente rápido. A menudo he tenido discusiones con colegas en las que bromeaban mencionando que todo lo que quieren saber de mí es "¿la computadora dice sí/no?" El tiempo que puede tomar algo nuevo a menudo se subestima, tener que escribir pruebas continuamente generalmente se considera una pérdida de tiempo. Lo que me lleva a mi siguiente punto....

El buen software no se valora en la academia, al menos no de la misma manera que en la industria

La medida de competencia en la academia son las publicaciones, y la forma de vigencia son las citas. Estás constantemente en una forma de competencia para encontrar algo nuevo y útil, y solo el primero obtendrá el premio. Los clones no existen ni sobreviven durante mucho tiempo en el mundo académico. Por el contrario, en la industria puede ganar cuotas de mercado mediante una mejor publicidad, una GUI más fresca o un precio más bajo. En la academia, si algún método ya está publicado, necesitas hacer otra cosa.

Del mismo modo, si ya ha publicado un método, las características adicionales, la limpieza, la optimización, etc. de ese software de prueba de principio a menudo no son lo suficientemente buenos como para justificar una nueva publicación, lo que prácticamente significa que ha desperdiciado meses de trabajo en vano. . Triste pero cierto...

Las expectativas cambian, tienes que esperar lo inesperado

Puede ser un punto pequeño, pero no puedo enfatizarlo lo suficiente, ya que ha llegado a morderme en la espalda una y otra vez. Simplemente no obtiene las especificaciones adecuadas para un nuevo proyecto. A menudo son demasiado vagos o demasiado estrictos (poco realistas). A veces, algo que nunca se mencionó resulta ser implícitamente esperado. Luego, para colmo de males, las especificaciones cambian en función de un nuevo formato de datos, alguna otra base de datos, nuevas características o simplemente esa otra cosa genial en la que el jefe estaba pensando cuando estaba en una conferencia... Usted escribe y reescribe soluciones para el mismo problema, se convierte en un desorden.

Por lo general, no recibe el apoyo que necesita

Los pocos estudiantes de doctorado en programación en mi departamento intentamos mejorar manteniéndonos al día con las tendencias. Aprender las mejores prácticas, por ejemplo, a través de SO. Pero la mayoría de las veces, cuando quieres probar algo nuevo, ves obstáculos; o el departamento de TI piensa que eres una molestia, o el jefe piensa que estás holgazaneando, o las personas a las que les pides ayuda piensan que no sabes una mierda y que estás perdiendo el tiempo . Por ejemplo, me tomó varios meses de negociaciones y correos de ida y vuelta para poder acceder a nuestro servidor de control de versiones desde casa. Eventualmente, solo funciona más rápido para omitir ciertas mejores prácticas.

Las tendencias más recientes y geniales de CS no siempre están bien documentadas para personas que no son expertas

He tratado de ensuciarme las manos con varias tecnologías "nuevas", que a menudo tienen una curva de aprendizaje empinada. A veces realmente no vale la pena el esfuerzo. El mejor ejemplo que tengo es Maven. Como a menudo trabajo en Java, pensé que debería usar herramientas modernas para empaquetar y administrar dependencias. Pero mi conclusión, después de haber luchado con él durante tanto tiempo, ¡es @%&$! Realmente no tengo la energía o el tiempo para revisar ese lío de documentación.

Línea de fondo

Después de sufrir por esto en los últimos años, llegué a la siguiente conclusión que me dio algo de paz interior:

" No soy un desarrollador de software. No estoy educado ni me pagan por escribir software. Escribir software no es mi trabajo; aprender a resolver ciertos problemas sí lo es " .

Espero que esta respuesta le brinde algunas ideas sobre por qué el software escrito por científicos (excepcionalmente talentosos o no) a menudo no cumple con los estándares establecidos por los desarrolladores de software.

Solo para complementar las excelentes respuestas de Marc Claesen y cbeleites . En la academia, cuando la gente escribe código, es común que:

• Los problemas a menudo son abiertos , por lo que quizás la estructura de datos con la que la gente comienza se usará más tarde para otra cosa, para lo cual no es óptima. Además, muchas cosas no están bien diseñadas, porque todo cambia. Compárelo con escribir un software comercial típico, donde las cosas se especifican desde el principio y, por lo general, están lejos de ser vanguardistas (incluso si son exigentes, no "la primera vez").
• La capacidad de mantenimiento no es un requisito : una pequeña pieza de software, que no se usa más tarde, sin que nadie más se haga cargo del código (y es mucho más fácil entender el propio código que el código de otros, incluso si es caótico, usted saber qué es dónde). Compárelo con una situación en la que, después de que el autor se vaya, alguien más se ocupará del código (o uno debe considerar constantemente contratar a un desarrollador más para acelerar el progreso).
• Las personas trabajan solas o con código heredado : situaciones muy opuestas, pero con resultados similares. En el primer caso (como el anterior), la gente puede entender su código caótico; en el segundo (por ejemplo, modificar piezas en el antiguo código Fortran), la gente tiene que adoptar para hacer cambios pequeños, a menudo, no imprevistos, adoptando la base de código existente.

Personalmente (viniendo de una formación académica pura), he aprendido la mayoría de las buenas prácticas de codificación, al colaborar con otros:

• aprendiendo de otros - algunas prácticas de codificación no requieren mucha capacidad intelectual, pero sí mucha experiencia - la sabiduría dice que una "solución inteligente" dada será problemática de mantener a largo plazo (como la mayoría de los errores (= feos trucos ) ),
• al colaborar , muchas veces me di cuenta de que lo que estaba razonablemente claro para mí, era totalmente ininteligible cthulhu fhtagn(pero poderoso) para otros (y al revés también: un buen código para otra persona era un acertijo desafiante para mí),
• en general, muchas buenas prácticas se están dirigiendo de hecho al mínimo común denominador de la habilidad (y las personas poco inteligentes ya lo están cerca); código inteligente por uno será difícil para otros.

Y un postre - la maldición de los superdotados , un comentario al último punto:

Eres un brillante implementador, más capaz que yo y posiblemente (lo digo después de considerarlo y con toda seriedad) el mejor en la tradición de Unix desde el mismo Ken Thompson. Como consecuencia, sufres la maldición del programador dotado: te apoyas tanto en tu habilidad que nunca has aprendido a valorar ciertos tipos de codificación, autodisciplina y diseño artesanal que los mortales menores deben desarrollar para manejar el tipo . de la complejidad del problema que comes en el desayuno.

(Fuente: http://lwn.net/2000/0824/a/esr-sharing.php3 ; o abreviado: http://www.linuxtoday.com/infrastructure/2000082800620OPCYKN )

Y fue dirigida por Eric S. Raymond a Linus Torvalds ...

Y como nota al margen (dado que la programación es cada vez más frecuente), ahora los científicos se dan cuenta de que las buenas prácticas y los flujos de trabajo son importantes, consulte, por ejemplo, http://software-carpentry.org/ .

¿Por qué Roald Amundsen no pavimentó una carretera al Polo Sur?

¿Por qué Edmund Hillary no construyó un telesilla en su camino al Monte Everest?

El trabajo de los académicos es encontrar soluciones a problemas que antes se consideraban imposibles, enseñar a otros (y, a pesar de lo repetitivo de sus propuestas de subvenciones, este público objetivo son otros investigadores) cómo resolver el problema y hacer lo anterior de la manera más eficiente posible.

Los académicos se preocupan por la calidad de su código solo en la medida en que funcione "lo suficientemente bien" como prueba de concepto de sus ideas y, posiblemente, que pueda reutilizarse en proyectos futuros. Refactorizar el código, escribir la documentación, verificar cuidadosamente los errores, configurar compilaciones automatizadas, etc. es una pérdida de tiempo, a menos que el tiempo invertido en mejorar el software les ahorre al menos el mismo tiempo en la generación de resultados de trabajo. Para los cuatro elementos que he enumerado, este casi nunca es el caso.

Sin duda, cuando su investigación resulte ser importante en la práctica, muchos investigadores regresarán y escribirán implementaciones bien diseñadas de sus algoritmos anteriores (generalmente como parte de un acuerdo de consultoría con desarrolladores de software profesionales), y tenían la capacitación y el talento. hacerlo antes, simplemente no valía la pena.

Incluso siendo un desarrollador de software profesional, ¿podría desarrollar lo que llama un buen software cuando los requisitos varían de manera impredecible cada semana? Este es el mundo donde los investigadores viven y sobreviven.

Hacer investigación científica significa adentrarse en áreas inexploradas. Los investigadores no saben qué características pueden necesitar del monstruo mañana por la mañana. Esto depende de los resultados que obtengan hoy a la medianoche. Un programa científico acumula demasiadas iteraciones, agregando características que nadie pensó que serían necesarias.

Cualquier intento de dejar espacio para nuevas funciones, agregar modularidad, a menudo incluso empeora las cosas cuando estos "enfoques genéricos" deben modificarse más tarde para hacer modificaciones mucho más drásticas de lo que se esperaba (y respaldaba) por el "marco genérico". .

Como resultado, un programa que evoluciona directamente durante el proceso de investigación a menudo solo se puede utilizar como prototipo y debe reescribirse antes de lanzarlo como software comercial o también FOSS. Un programador profesional, si es contratado, probablemente podría hacerlo algo mejor, pero la inestabilidad de los requisitos probablemente impida la "llegada" al gran diseño final de todos modos.

En muchos aspectos, escribir software es un arte. Muchos grandes pintores no han nacido así, en realidad aprendieron el arte en años de entrenamiento y con muchos malos resultados en el medio.

Toma una hoja de papel e intenta dibujar a alguien que conozcas. Incluso si tienes una imagen frente a ti, lo más probable es que parezca cómica. Ahora, un verdadero artista te preguntaría por qué no viste las sombras, no pudiste encontrar la perspectiva correcta o pusiste las orejas en una posición completamente incorrecta a pesar de que tenías una imagen clara frente a ti. Sin embargo, no es su arrogancia lo que causó eso, es su falta de experiencia en mirar el modelo de la manera correcta. Técnicamente tiene algo que ver con que uses la mitad equivocada de tu cerebro, y puedes ser entrenado para cambiar eso. Solo que no hasta mañana.

Los científicos trabajan basados ​​en la teoría. Tienen una teoría, quieren probarla, escriben código centrándose solo en la teoría real en cuestión. Ese eres tú viendo una nariz, pero no las sombras a su alrededor. Si les enseñara durante un mes o tal vez años a usar las técnicas y los "trazos" correctos para hacerlo de la manera correcta, podrían cambiar. Sin embargo, debe preguntarse si vale la pena el tiempo. A veces lo es, pero a veces los científicos deberían apegarse a las cosas científicas tanto como los pintores no deberían comenzar repentinamente con la química radiactiva de la nada.

Si decides enseñarles, ten en cuenta la idea del artista que empieza en su primer día: no es su arrogancia, es su falta de conocimiento sobre cómo usar las partes correctas del cerebro. Hay una razón por la cual "Desarrollo de software" es un aprendizaje de 3 años, después de lo cual se le considera un nivel "principiante".

Gran discusión, y he pensado lo mismo muchas veces. También hay otro tipo de software, que en realidad no se menciona anteriormente: programas desarrollados dentro de la academia que no forman parte de un proyecto de investigación. Hay muchos proyectos de desarrollo de software que están más centrados en la logística, la enseñanza, etc. (clickers, captura de video, intranets, software de biblioteca, etc.). A veces, estos se manejan profesionalmente y se convierten en proyectos de colaboración, etc., pero muy a menudo son el resultado de que alguien tenga algunos asistentes graduados que saben un poco de programación, que codifican algo que tal vez funcione, pero por supuesto no tiene documentación, prueba, versión control, documentación de requisitos, etc., y cuando se gradúen y sigan adelante, buena suerte para cualquiera que quiera intentar mantenerlo ... Parte de esto también es la "falsa economía"

Personalmente, probablemente también sea responsable de algún software de mala calidad, como estudiante de doctorado en aprendizaje asistido por computadora. Con suerte, estoy un poco más al tanto de las mejores prácticas, el control de versiones, etc. que muchos, pero nunca he tenido ninguna capacitación profesional y, lo que quizás sea más importante, nunca he sido parte de una comunidad de práctica, asesorado por mejores investigadores. etc. En la educación, es de alguna manera aún más difícil, porque hay muy pocos estudiantes/profesores técnicamente inclinados. Por supuesto, uso mucho SO, listas de correo, etc., pero estoy seguro de que mi código podría mejorarse enormemente si tuviera un colega senior en el pasillo que revisara mi código y me proporcionara comentarios, etc.

De hecho, uno de los comentarios anteriores me hizo pensar en esto: es bastante común que las universidades tengan consultores estadísticos que, en cierta medida, están disponibles para los investigadores. (Tenemos a alguien en nuestra biblioteca a quien podemos acceder de forma gratuita durante una o dos horas, y luego tenemos que pagar una tarifa, pero sé que muchas personas lo aprovechan y me resultó muy útil sentarme con ellos y pasando por su diseño de investigación, sus supuestos, el diseño estadístico, etc.). Sería un concepto interesante tener un "consultor de desarrollo de software" (no estoy seguro del título), que básicamente sería un revisor de código profesional... Pero también podría extenderse para ayudar a las personas a pensar en sus necesidades, descubrir marcos útiles o bibliotecas, control de versiones de navegación, licencias de código abierto, etc.

Y, por supuesto, cambiar el sistema de incentivos para premiar la liberación (¡o la mejora!) de código de alta calidad es increíblemente importante, pero muy difícil. Creo que el ejercicio de Revisión del Código Académico de Mozilla es un experimento realmente interesante en este sentido.

Volver a escribir secuencias de comandos de Python para analizar los registros de clics de MOOC :)

Porque programar es como andar en auto: todos lo necesitan, pero la mayoría de nosotros no somos profesionales. ¿Cómo se aprende a programar? Generalmente compra/presta un libro "Python o lo que sea para principiantes". Se tratará de cómo guardar un archivo, cómo ejecutar un programa y cómo llamar a una función. Después de esto, puedo hacer lo que más necesito ahora o ayer.

¿Dónde aprenderé sobre patrones de diseño, buenas prácticas de desarrollo de software, desarrollo ágil, cómo escribir buen código? ¡EN NINGÚN LUGAR! Al igual que después de tomar un curso de manejo de un automóvil, creo que estoy bien, y no leo 5 horas al día sobre cómo conducir más rápido en una carretera mojada, no voy a las librerías y leo todos los libros de CS, que puede estar relacionado conmigo. ¡Incluso si voy a la red, tal vez Software Carpentry sea el único recurso relevante! En serio, si alguien sabe algo similar, por favor, ¡la publicación está en algún lugar aquí!

No voy a trabajar a la luz de la luna para aprender un curso completo de CS en el MIT para armar mi "Hola palabra" del día. Y no me sorprendería si incluso los chicos de CS en el MIT aprendieran la mitad de las buenas prácticas de programación fuera de la escuela, en el trabajo, y no después de 4 o 5 años sentados en la escuela.

resumen: replicación o ausencia de la misma.

detalles:

Mis observaciones (desafortunadamente, n pequeña y un solo punto de vista) son que la razón principal por la que tanto los científicos talentosos como los que no lo son escriben un software horrible es simplemente "lo opuesto a la replicación". No ven ningún valor en la investigación reproducible, no anticipan que su trabajo será replicado y ciertamente no desean que su trabajo sea replicado. (Solo quieren que su trabajo sea citado :-)

Soy un BSCS que pasó un tiempo "en la industria", incluido un conocido acrónimo sin rostro. Todos los codificadores que conocía al menos usaban y valoraban el software de código abierto, y muchos contribuyeron (especialmente en mi último concierto de código directo). El OSS solo se valora en la medida en que se usa y se extiende. (AFAICS: ¿me estoy perdiendo algo? ¿Lenguajes exóticos que se estudian pero no se usan?) Por supuesto, un OSS dado solo se usa si es robusto, probado/comprobable, bien documentado, etc. (y solo se extiende si es público).

Ahora he vuelto a la escuela como modelador ambiental (principalmente atmosférico). Las personas con las que he trabajado en su mayoría ni siquiera ponen su código en repositorios públicos (incluso los que son mucho más jóvenes que yo, esto no es un problema generacional AFAICS), mucho menos crean documentación, modularidad, comentarios (ya sea en código o en confirmaciones), y las otras prestaciones que uno espera en OSS. Esto parece deberse (basado únicamente en la conversación, no en datos empíricos sólidos) a su suposición (y, por lo general, a la esperanza) de que su código no solo nunca será utilizado por nadie más (y, de hecho, probablemente nunca será utilizado nuevamente por el codificador). ), pero ni siquiera ser visto .

Desafortunadamente, no entendí esto cuando "contraté" como estudiante de posgrado. (No sabía casi nada acerca de la academia de posgrado; simplemente había "saltado por la ventana" con el acrónimo sin rostro y solo sabía en qué quería trabajar, y no tenía ni idea de las diferencias culturales entre la informática ("ciencias de la computación" siendo famosamente mal llamado) y "ciencias duras".) Elegí como mi asesor al profesor cuya área de trabajo más me interesaba. Una vez que comencé a mirar su código, mi vómito fue un proyectil. Traté de hablar con él al respecto, y su actitud fue aproximadamente (es decir, no es una cita) "los papeles importan, el código no". Nunca envió código con documentos ni lo hizo público, y usó casi exclusivamente un {lenguaje, entorno de desarrollo} bastante oscuro, {propietario, costoso} (como, para ser justos, hacen muchos de sus colegas, algunos de los cuales son nombres muy importantes en nuestro pequeño campo). Con algunos antecedentes en filosofía de la ciencia y sabiendo que los modelos en los que trabajamos tienen implicaciones reales de política pública (por ejemplo, gastos importantes), pregunté cómo se podrían reproducir sus resultados. Dijo (y esta es una cita) "tienen que confiar en nosotros, somos científicos". Ya no es mi asesor...

Si bien sospecho (nuevamente, en n pequeña) que las observaciones anteriores "miden la tendencia central", no todo es oscuridad y vacío :-) En mi propio campo, existe un software ejemplar como GEOS-Chem . Desafortunadamente, GEOS-Chem "es lo que es" en gran parte (en mi humilde opinión) gracias al equipo de soporte de GEOS-Chem , que proporciona una especie de infraestructura asombrosamente rara en mi campo. Por lo tanto, sospecho que GEOS-Chem es, si la calidad del software se mide en este dominio con alta cobertura (¿me estoy perdiendo algo?), probablemente 2-4σ mejor que la media.

La respuesta corta a esta pregunta es que los científicos investigadores (en su mayoría) no son programadores de software (aunque publican software de vez en cuando).

Trabajo en un campo computacionalmente pesado, lo que significa que muchas de las cosas misceláneas en las que he trabajado en el pasado pueden empaquetarse en un software. Desde mi propia experiencia, aquí hay algunos obstáculos que me impiden escribir un software completo basado en mi trabajo:

1. Gran parte de mi investigación implica investigaciones abiertas, por lo que el código también está escrito para ese propósito . Escribir un software implica que tengo una comprensión esencial de todo lo que he investigado hasta ahora, lo cual no es el caso (y no será el caso en el futuro previsible).

2. Cada una de las cosas en las que he trabajado es demasiado pequeña individualmente para ser escrita como un software . Ampliar el alcance de las cosas requiere investigación, no software.

3. Gran parte de la investigación está fuera de mi control. Siempre habrá nuevas oportunidades y direcciones para la investigación, lo que significa que se cancelará alguna investigación (y el código escrito junto con ella) , esto se remonta a los puntos mencionados anteriormente.

4. La mayor parte del tiempo escribo código MATLAB en el sistema operativo Windows. Incluso si no cambio mi sistema operativo (por ejemplo, Linux), mis opciones son traducir el código de MATLAB a algún lenguaje .NET o exportarlo como un objeto C/C++. Puede que me equivoque, pero creo que el desarrollo de software en cualquiera de los dos idiomas es difícil y requiere mucho tiempo .

5. La razón por la que la mayoría de los ingenieros de investigación escriben código con MATLAB es que el tiempo de respuesta en la investigación tiene una gran variación. La mayoría de las veces, las cosas deben hacerse semanalmente, y esto puede implicar experimentos muy novedosos. Cuando se llena, el tiempo de respuesta puede ser dentro del día. Estos experimentos se realizan de manera óptima utilizando una plataforma muy estable como MATLAB o Mathematica , mientras que, para algunos otros lenguajes, su código no se puede compilar si accidentalmente inserta una pestaña en algún lugar o pierde dos puntos. Una vez más, esto alimenta las cosas que he mencionado en los puntos anteriores y deteriora aún más las habilidades adecuadas de desarrollo de software, aunque esté escribiendo código.

6. Un comentarista mencionó que el desarrollo de software está funcionando muy bien en el aprendizaje automático. Desde mi perspectiva, la razón de esto es que, en campos como la optimización, el aprendizaje automático, el procesamiento de señales, A. las cosas son visualizables, B. las cosas se han estudiado desde la década de 1950, C. mucha gente está tratando de entrar en este campo, D. muchas cosas son honestamente fáciles, computacionalmente hablando y muchas veces una solución inexacta (que funciona en casos muy especiales) es suficiente. Desafortunadamente, la mayoría de nosotros no trabajamos en campos tan convenientes .

7. Francamente, todos tenemos vidas más allá de la investigación . El desarrollo de software podría requerir un compromiso personal o una colaboración que dure más que la duración total de un proyecto de investigación.

No creo que sea un investigador talentoso, pero he investigado en software y lo que realmente produjo una pieza de software. Para esa pieza, también colaboré con un grupo de personas en una importante empresa de tecnología. Obviamente, hubo muchas diferencias entre nuestro enfoque del software.

• Cuando escribí el software, elegí el camino más fácil para demostrar que mis ideas deberían ser correctas. No pasé mucho tiempo diseñando el software, ¡porque no tenía tiempo! Me esforcé mucho para que funcionara, y lo intenté para que fuera legible y pirateable (porque sé que alguien más se hará cargo eventualmente), pero no dediqué mucho tiempo a diseñarlo. Estaba principalmente interesado en hacer que funcionara para poder hacer cosas con él (¡y demostrar que mis ideas son correctas!)

• Esa fue en realidad la parte buena. En mi investigación, utilizamos una biblioteca de software de investigación creada por otro grupo de investigación en otro país. ¡En realidad no sabían que la gente estaba usando su software! Como resultado, verificaron los cambios que dieron como resultado que el software no se compilara. Además, el código era difícil de leer y no podemos arreglarlo nosotros mismos (era C++, por lo que los mensajes de error tampoco son tan útiles). Tuvimos que contactarlos personalmente para arreglar eso.

• Entonces, ¿pueden los académicos escribir buen software? Sí, al menos muchos podrían (o no podrían dar cursos de programación). De hecho, había un profesor mío que era un instructor de programación fenomenal, pero cuyo código escrito personalmente no era tan agradable de leer. Los académicos simplemente no tienen tiempo para piratear y hacer que su código se vea bien. Si hubieran tenido más tiempo para mejorar su software, estoy seguro de que lo harían.

• OTOH, la gente de la compañía de tecnología estaba realmente interesada en producir software que pudieran usar (y, a través de eso, tal vez producir algunos trabajos de investigación). Siguieron sus estándares de codificación. Lo diseñaron profundamente. Utilizaron gestión de compilación, pruebas de integración y pruebas de cobertura. Lo hacen porque (1) tienen tiempo y dinero, y les pagan por hacerlo, y (2) ¡realmente van a usarlo!

Las cualidades que hacen a un buen científico no siempre hacen a un buen programador de software (excepto, como señaló el OP, cuando la "ciencia" es la informática.

La codificación informática es un arte de gran precisión. Muchas personas, incluidos los buenos científicos, no son lo suficientemente precisas para escribir un buen código con facilidad. Esto es particularmente cierto en el caso de los tipos de científicos más "intuitivos".

Muchos científicos encuentran que la programación de computadoras es "aburrida" y, por esta razón, no les va bien. Es cierto que la ciencia "regular" requiere un trabajo detallado, pero no al grado de la programación, que muchos (incluido el suyo) encuentran "aturdidor".

Básicamente, si hay una correlación nula (o muy débil) entre un buen científico y un buen programador, obtendrá toda la gama de habilidades de programación, buenas, medianas y terribles de una población de científicos.

Hay tres razones principales.

Una es que los científicos no son desarrolladores de software profesionales. Eso es cierto incluso para los informáticos, y más aún para los matemáticos, físicos, químicos, biólogos, científicos sociales, etc. No es que no pudieran, la mayoría de las personas que son razonablemente inteligentes podrían convertirse en desarrolladores de software profesionales si quisieran, pero la mayoría no lo son.

La segunda es que los científicos no están interesados ​​en crear lo que sea lo opuesto a un "software horrible". Por lo general, solo están interesados ​​​​en los resultados. Donde esto es malo es si su software contiene errores que producen resultados incorrectos, pero lo suficientemente cerca de la verdad como para parecer plausibles. Afortunadamente, muchos errores producirán resultados que obviamente son incorrectos. También es malo si el software es lo suficientemente confuso como para que nadie pueda afirmar con certeza si es correcto o no, pero que yo sepa, no hay muchas quejas al respecto.

Y la tercera es que los científicos a menudo están bajo presión de tiempo. Pueden escribir software rápidamente que saben que debe mejorarse, e incluso pueden saber cómo mejorarlo, pero simplemente no tienen tiempo.

Una cosa que realmente espero que no sea la razón es que algunas personas piensan que cualquier cosa que entiendan debe ser simple y que cualquier cosa que no entiendan debe ser difícil. Con estas suposiciones, cualquier científico que escriba software que nadie pueda entender se considerará un genio, mientras que cualquiera que escriba software que sea fácil de entender no sería nada impresionante. Entonces, lo que hace un desarrollador de software profesional, crear software que sea fácil de entender, estaría dañando su carrera a la vista de estas personas. Realmente espero que esto no sea lo que suceda, pero no me sorprendería.