¿Fomentando buenas prácticas de desarrollo para progtwigdores no profesionales?

En mi copioso time libre, queueboro con varios científicos (en su mayoría biólogos) que desarrollan software, bases de datos y otras herramientas relacionadas con el trabajo que realizan.

En general, estos proyectos se construyen de manera puntual, se usan internamente y, finalmente, alguien decide "oh, esto podría ser útil para otras personas", por lo que lanzan un binary o le dan una interfaz PHP y lo introducen en el web. Sin embargo, normalmente no pueden molestarse en poner a disposition de otros desarrolladores su código fuente o volcados de sus bases de datos, por lo que en la práctica, estos proyectos generalmente mueren cuando el proyecto para el cual se escribió el código llega a su fin o pierde backgrounds. Unos meses (o años) después, algún otro laboratorio necesita el mismo tipo de herramienta, tienen que repetir el trabajo que hizo el primer laboratorio, ese proyecto finalmente muere, se enjabona, enjuaga y repite.

¿Alguien tiene alguna sugerencia sobre cómo convencer a las personas cuyo trabajo principal no es la progtwigción de que beneficia a su comunidad para que sean más abiertos con las herramientas que han creado?

Del mismo modo, cualquier consejo sobre cómo comunicar la idea de que el control de versiones, el seguimiento de errores, la refactorización, las testings automatizadas, la continuous integration y otras prácticas comunes que los desarrolladores profesionales dan por hecho son buenas ideas en las que vale la pena dedicar time.

Desafortunadamente, muchos científicos parecen tener la opinión de que la progtwigción es un mal aburrido y necesario, y que su investigación es mucho más importante, sin darse count de que en estos días, el desarrollo de software es parte de la investigación científica, y si la comunidad un todo elevaría el nivel de los estándares de desarrollo, todos se beneficiarían.

¿Alguna vez has estado en una situación como esta? ¿Qué funcionó para ti?

Software Carpentry suena como una coincidencia para su request:

Visión de set

Muchos científicos e ingenieros pasan la mayor parte de su vida progtwigndo, pero solo a un puñado se le ha enseñado cómo hacerlo bien. Como resultado, pasan su time luchando con software, en lugar de investigar, pero no tienen idea de cuán confiables o eficientes son sus progtwigs.

Este curso es una introducción intensiva a las prácticas básicas de desarrollo de software para científicos e ingenieros que pueden networkingucir el time que dedican a la progtwigción en un 20-25%. Todo el material es de código abierto: puede ser usado libremente por cualquier persona con fines educativos o comerciales, y se alienta activamente a los grupos de investigación de la academia y la industria a que lo adapten a sus necesidades.

Permítanme prólogo al decir que soy bioinformática, así que veo las cosas de las que siempre habla. Hay algo de verdad en el hecho de que muchas de estas personas son biólogos convertidos en codificadores que simplemente no están expuestos a las mejores prácticas.

Dicho esto, el problema principal no es que estas personas no conozcan las buenas prácticas o no les importe. El problema es que no hay ningún incentivo para que pasen más time aprendiendo ingeniería de software, o que limpien su código y lo liberen.

En un entorno de investigación académica, su reputación (y, por lo tanto, sus futuros puestos de trabajo) depende casi por completo de la cantidad y la calidad de las publicaciones a las que ha contribuido. Las publicaciones sobre methods o algorithms nuevos no reciben tanto respeto como las que informan nuevos hallazgos biológicos. Entonces, después de hacer un análisis rápido de un set de datos, hay muy pocos incentivos para dedicar mucho time a limpiar mi código y liberarlo, cuando podría pasar al siguiente set de datos y hacer más descubrimientos biológicos.

También notaré que la disponibilidad de backgrounds para el desarrollo computacional es de una magnitud menor que la disponible para hacer la biología. En un clima donde solo el 10% de las subvenciones presentadas se financian, los científicos no pueden darse el lujo de tomarse el time para limpiar y publicar su código, cuando hacerlo no les ayuda a mantener su laboratorio financiado.

Entonces, está el problema en pocas palabras. Como bioinformática, creo que es perverso y a menudo frustrante.

Dicho esto, hay esperanza para el futuro. Con la secuenciación de segunda y tercera generación, en particular, la biología se está moviendo hacia el campo del descubrimiento de alto performance, donde la minería de datos y los sólidos conductos computacionales se vuelven esenciales para el éxito de la ciencia. A medida que eso ocurra, verá más y más backgrounds para proyectos computacionales, y más y más ingeniería de software real sucediendo.

No es exactamente simple, pero la demostración con ejemplos probablemente dirija el punto de la forma más efectiva: encuentre una tarea que el investigador necesite hacer, encuentre a alguien que se tome el time para hacer una herramienta con la fuente disponible, y señale cuánto time el investigador podría ahorrar como resultado de tener esa herramienta disponible, y luego señalar que podrían devolver a la comunidad de la misma manera.

En efecto, lo que les pides que hagan es convertirse en desarrolladores profesionales (con su abundante time libre), además de la profesión elegida. Su renuencia es comprensible.

¿Alguien tiene alguna sugerencia sobre cómo convencer a las personas cuyo trabajo principal no es la progtwigción de que beneficia a su comunidad para que sean más abiertos con las herramientas que han creado?

Rendirse. En serio, esto es como enseñarle a un cerdo a cantar. (Puedo decir esto porque solía ser físico, así sé cómo son).

El problema real es que sus colegas son recompensados ​​por resultados científicos medidos en publicaciones, no en software. Ya es bastante difícil en informática para ser reconocido por la construcción de software; en las otras ciencias, es casi imposible.

No puedes vender buenas prácticas de desarrollo a tus amigos de biología con el argumento de que "es bueno para ti". Van a preguntar "¿debería invertir esfuerzo para aprender sobre buenas prácticas de software, o debería invertir el mismo esfuerzo para publicar otro documento de biología?" No contestar.

En realidad, pedirle a cualquier equipo ocupado del proyecto que incluya en su agenda el time para hacer que su software sea adecuado para su adopción por otro equipo es extremadamente difícil en mi experiencia.

Hacer un trabajo extra para el bien público es una gran pregunta.

He visto un patrón común de "recolección" después de que el proyecto está completo, lo que refleja que la encoding inmediata para la reutilización tiende a perderse en la urgencia del día.

La única avenida en la que puedo pensar es si la reutilización está dentro de una organización con un presupuesto para un "cazador recolectador", alguien cuya razón para estar allí es TI.

Es posible que ganes más por cosas como las testings unitarias porque tienen una amortización inmediata para el desarrollo.

Tal vez enmarcarlo en términos de responsabilidad académica / intelectual ayudaría, hasta cierto punto, compartir su fuente es, de muchas maneras, como citar correctamente sus fonts o detallar su metodología de investigación. Hay arguments similares que deben hacerse para algunos de los comportamientos de "desarrollador de software profesional" que le gustaría alentar, aunque creo que liberar el código es probablemente una venta más fácil por estos motivos que otras cosas que podrían requerir mucho más trabajo.

Por un lado, ¿podríamos dejar de enseñar a los biólogos Perl? Enseñar a los progtwigdores no profesionales un lenguaje de escritura está prácticamente garantizado para llevar a un código desechable que no se puede mantener. Python ocupa el mismo nicho, es igual de fácil de aprender (¡incluso se usa para enseñar a los niños a progtwigr!), Y es mucho más legible.

Dibuja paralelismos con las statistics. Las statistics son una parte crucial de la investigación científica, y una donde el único consejo sensato es: o aprende a hacerlo correctamente, o haz que un experto lo haga por ti. Las statistics incorrectamente hechas pueden socavar completamente un documento, del mismo modo que un código mal escrito puede socavar por completo una database pública o un recurso web.

PD: Este blog es muy bueno, pero lograr que lo lean será una lucha cuesta arriba: Progtwigción para científicos

Chris,

Estoy de acuerdo contigo hasta cierto punto, pero en mi experiencia lo que termina sucediendo es que en su afán por publicar terminas con demasiados códigos y methods "yo también", que en realidad no aumentan la calidad de la ciencia. Si se pensara un poco más en el código abierto de abastecimiento y se alentara a otros a contribuir (sin necesariamente get publicaciones de él), todos se beneficiarían.

Definitivamente estoy de acuerdo en que una separación entre los progtwigdores científicos y los ingenieros de software es algo bueno, especialmente para aplicaciones de producción. Pero incluso para la progtwigción científica, la calidad de mi código hubiera sido mucho mejor si hubiera seguido buenas prácticas en ese momento.

En mi experiencia, la mejor manera de hacer que la gente programe limpiamente es mostrar un buen ejemplo cuando se trabaja con ellos. por ejemplo: "Nunca paso días sin remedio depurando mi código porque lo primero que codigo son testings unitarias automatizadas que detectarán problemas cuando son pequeños y fácilmente detectables" o: "Soy muy malo en el seguimiento de versiones de cosas, pero a veces mi nuevo código rompe lo que funcionaba antes. Así que uso svn / git / dropbox para hacer un seguimiento de las cosas para mí "

En mi experiencia, ese tipo de afirmación puede despertar el interés de "los biólogos que aprendieron cómo guionizar". Y si necesita queueborar en un proyecto más grande, deje en claro que tiene más experiencia y que todo irá más tranquilo si las cosas se hacen a su manera.


Con respecto a la publicación del código, la práctica actual es realmente frustrante. Me gustaría ver una nueva revista como Source Code for Biology and Medecine, donde el código es revisado por pares y puede publicarse, pero eso no tiene (o muy poco) costos de publicación. Poner código en sourceforge u otros de hecho no es "científicamente valer la pena" porque no hace una línea en su list de publicación, y la mayoría del código no es lo suficientemente revolucionario como para justificar el pago de $ 1,000 para publicación en Source Code for Biology and Medecine o PLoS One …

Podrías hacer que usen un sistema de administración de contenido, como Joomla. De esa forma solo empujan contenido y no codifican.

No convencería tanto como simplificaría el process. Documentarlo con claridad, hacer videos tutoriales y agrupar algún tipo de cadena de herramientas que hace que sea ridículamente fácil configurar los repositorys de origen sin tener que convertirse en expertos en algo que no es su campo principal.

Tome un progtwigdor realmente bueno que ya conozca las mejores prácticas, pida a sus científicos que le enseñen lo que necesitan y lo que hacen, eventualmente el progtwigdor tendrá un conocimiento mínimo de dominio (sospecho que se tarda entre 1 y 3 años dependiendo del dominio) para hacer lo que los científicos piden

Los desarrolladores siempre aprenden otro dominio de competencia, porque la mayoría de sus progtwigs no son para desarrolladores, por lo que necesitan saber lo que hace el "cliente".

Para ser el abogado del diablo, ¿enseñar a los científicos a ser buenos ingenieros de software es lo correcto? El software en investigación suele ser muy específico: a veces hasta el punto en que un fragment de código necesita ejecutarse con éxito solo una vez en un solo set de datos. Los resultados luego se introducen en una publicación y se cumple el objective. Y existe un alto riesgo de que su técnica o algorithm sea reemplazado por uno mejor en poco time. Por lo tanto, existe un riesgo real de que se desperdicie el esfuerzo de producir código shiny.

Cuando te sientas frustrado por atravesar un pantano de código Perl mal formado, solo piensa que el código que estás viendo es uno de los pocos sobrevivientes. Se han escrito montañas de dicho código, se han usado algunas veces y luego se han desechado para no volver a ver la luz del día.

Supongo que solo estoy diciendo que hay un gran lugar en la investigación para el código de un prototipo excepcional apestoso. Hay buenas razones por las cuales existe dicho código. Puede que no sea lindo, pero si hace bien el trabajo, ¿a quién le importa? Siempre podemos contratar a un ingeniero de software para que escriba la versión list para producción más adelante, SI resulta ser justificada, y dejemos que nuestros científicos continúen.

Intereting Posts