wrike source software open manager management asana project-management

project-management - source - trello



Proyectos y desarrollo de software en un entorno de investigación. (6)

El tipo de ciencia grande que hago (física de partículas) tiene un pequeño número de proyectos grandes y de larga duración ( ROOT y Geant4 , por ejemplo). Estos son desarrollados principalmente por profesionales de la programación real. Usando procesos que serían reconocidos por cualquier otra persona en la industria.

Luego, cada colaboración tiene una serie de programas de todo el proyecto que se desarrollan en colaboración bajo la dirección de un pequeño número de científicos de programación de alto nivel. Estos utilizan al menos las herramientas básicas (siempre control de versiones, a menudo algún tipo de seguimiento de errores o compilaciones automatizadas).

Finalmente, casi todos los científicos trabajan en sus propios programas. El uso del proceso en estos programas es muy irregular y, a menudo, sufren de todos los males que otros han discutido (vidas cortas, habilidades de codificación deficientes, sin revisión, muchos mantenedores en serie, Síndrome de No Inventado, etc., etc.). La única ventaja que está disponible aquí en comparación con la ciencia de grupos pequeños, es que trabajan con las herramientas que mencioné anteriormente, por lo que hay algo que puede señalar y decir "Eso es lo que quiere lograr".

¿Cuáles son las estrategias útiles para adoptar cuando usted o el proyecto no tienen una idea clara de cuál será el producto final (si es que lo hay)?

Tomemos "investigación" para significar una exploración en un área donde muchas cosas no se conocen o implementan y donde un conjunto formal de entregables no se pueden especificar al inicio del proyecto. Esto es común en STEM (ciencia (física, química, biología, materiales, etc.), ingeniería tecnológica, medicina) y en muchas áreas de la informática y la informática. El software se crea como un fin en sí mismo (por ejemplo, un nuevo algoritmo), un medio para administrar datos (a menudo experimentales) y simulación (por ejemplo, materiales, reacciones, etc.). Generalmente es creado por grupos pequeños o individuos (omito la ciencia grande, como los telescopios y los colisionadores de hadrones, donde se pone mucho énfasis en la ingeniería de software).

El software de investigación se caracteriza por (al menos):

  • resultado desconocido
  • escala de tiempo desconocida
  • poca gestión formal del proyecto
  • presupuestos limitados (al menos en la academia)
  • Impredecibilidad de herramientas y bibliotecas de terceros.
  • Cambios en el mundo exterior durante el proyecto (p. ej., nuevos descubrimientos que pueden ser positivos: ahorre esfuerzos o sea negativo)

Los proyectos pueden ser desde días ("ver si esta es una dirección que vale la pena ir") a años ("este es mi tema de doctorado") o más. Con frecuencia, las personas no son contratadas como personas de software, pero descubren que necesitan escribir un código para realizar la investigación o que se infecten escribiendo software. En general, hay poco crédito para una buena ingeniería de software: el "producto" es una publicación de conferencia o revista.

Sin embargo, algunos de estos proyectos resultan ser muy valiosos: el área más obvia es la genómica, donde en sus inicios los científicos demostraron que la programación dinámica era una herramienta revolucionaria para ayudar a pensar en las proteínas y la estructura nucleica. Ahora esta es una industria multimillonaria ( o más). Lo mismo es cierto para los códigos de mecánica cuántica para predecir las propiedades de las sustancias.

La desventaja es que mucho código se desecha y es difícil de construir. Para intentar superar esto, hemos creado bibliotecas que se comparten en el grupo y en todo el mundo como Open Source (pero aquí nuevamente se da muy poco crédito). Muchos investigadores reinventan la rueda (programación "de cabeza hacia abajo" donde no se consulta a los colegas y programación de "héroe" donde alguien trata de hacerlo todo ellos mismos).

Demasiada formalidad al inicio de un proyecto a menudo desanima a la gente y se pierde la innovación (nadie pasará 2 meses escribiendo especificaciones formales y pruebas de unidad). Muy poco y malos hábitos son desarrollados y promulgados. Los cursos de programación ayudan, pero nuevamente es difícil hacer que la gente los haga, especialmente cuando confía en su buena voluntad. La tutoría es extremadamente valiosa pero no siempre exitosa.

¿Existen recursos en línea que puedan ayudar a persuadir a las personas a que tengan buenos hábitos de software?

EDITAR: Estoy agradecido por dmckee (abajo) por señalar una discusión similar. Todo es bueno y estoy particularmente de acuerdo con que el control de versiones es una de las cosas más importantes que podemos ofrecer a los científicos (se lo ofrecimos a nuestros colegas y obtuvimos una muy buena aceptación). También me gusta el enfoque del curso de Carpintería de Software mencionado allí.

Es extremadamente dificil El entorno que tanto usted como Stefano Borini describen es muy preciso. Creo que hay tres factores clave que propagan la situación.

  1. Pensamiento a corto plazo
  2. Falta de entrenamiento formal y experiencia.
  3. Rotación continua de estudiantes de posgrado / posdoctorados para soportar la peor parte del nuevo desarrollo

Pensamiento a corto plazo. Hay algunas razones por las que el pensamiento a corto plazo es la norma, la mayoría de ellos ya están bien explicados por Stefano. Además de la terrible presión para publicar y la falta de reconocimiento por la creación de software, destacaría el número de contratos a corto plazo. Simplemente hay muy poca ventaja para que más académicos junior (estudiantes de doctorado y posdoctorados) dediquen tiempo a planificar estrategias de software a largo plazo, ya que los contratos son de 2 a 3 años. En el caso de proyectos a más largo plazo, por ejemplo, aquellos que se basan en el código de simulación de un miembro permanente del personal, he visto algunas aplicaciones de ingeniería básica de software, como control de versiones simples, casos de prueba estándar, etc. Sin embargo, incluso en estos casos, La gestión de proyectos es extremadamente primitiva.

Falta de entrenamiento formal y experiencia. Esta es una seria desventaja. En astronomía y astrofísica, la programación es una herramienta esencial, pero la comprensión de los costos de desarrollo, particularmente los gastos generales de mantenimiento, es extremadamente deficiente. Debido a que los científicos normalmente son personas inteligentes, existe la sensación de que las prácticas de ingeniería de software realmente no se aplican a ellos, y que pueden "simplemente hacer que funcione". Con más experiencia, la mayoría de los programadores se dan cuenta de que escribir código que en su mayoría funciona no es la parte difícil; Mantenerlo y extenderlo de manera eficiente y segura es. Algunos códigos científicos son desechables, y en estos casos el enfoque rápido y sucio es adecuado. Pero con demasiada frecuencia, el código se usará y reutilizará durante los años venideros, lo que traerá la consiguiente pena a todos los involucrados.

Rotación continua de estudiantes graduados / postdoctorados para nuevos desarrollos. Creo que esta es la característica clave que permite que el enfoque académico del software continúe sobreviviendo. Si el código es terrible y demora días en comprenderlo y depurarlo, ¿quién paga ese precio? En general, no es el autor original (quien probablemente se haya ido). Tampoco es el miembro permanente del personal, que a menudo solo está involucrado periféricamente con nuevos desarrollos. Normalmente, el estudiante graduado está implementando nuevos algoritmos, produciendo enfoques novedosos, intentando extender el código de alguna manera. A veces será un postdoctorado, contratado específicamente para trabajar en agregar alguna característica a un código existente, y obligado por contrato a trabajar en esta área por una fracción de su tiempo.

Este modelo es enormemente ineficiente. Conozco a un estudiante de doctorado en astrofísica que pasó más de un año tratando de implementar una pieza de matemáticas relativamente básica, solo unos pocos cientos de líneas de código, en un código existente de n-cuerpos. ¿Por qué tardó tanto? Debido a que literalmente pasó semanas tratando de entender el código existente, horriblemente escrito, y cómo agregarle su cálculo, y meses más de forma ineficaz para depurar sus problemas debido a la estructura del código monolítico, junto con su propia falta de experiencia. Tenga en cuenta que casi no había ciencia involucrada en este proceso; simplemente perdiendo el tiempo lidiando con el código. ¿Quién finalmente pagó ese precio? Solo ella. Ella fue la que tuvo que dedicar más horas para tratar de obtener suficientes resultados para hacer un doctorado. Su supervisor tendrá otro estudiante graduado después de que ella se haya ido, y así continúa el ciclo.

El punto que trato de señalar es que el problema con el proceso de creación de software en el mundo académico es endémico dentro del propio sistema, una función de los recursos disponibles y el tipo de trabajo que se recompensa. La cultura está profundamente arraigada en toda la academia. No veo una manera fácil de cambiar esa cultura a través de recursos externos o capacitación. Es el sistema en sí mismo el que debe cambiar, para recompensar a las personas por escribir un código sustancial, para realizar un mayor control sobre la corrección de los resultados obtenidos con el uso del código científico, para reconocer la importancia de la capacitación y el proceso en el código, y para responsabilizar a los supervisores del desperdicio. El tiempo de los integrantes de su grupo de investigación.

La parte más difícil es la transición entre "esto es solo para un papel" y "realmente vamos a usar esto".

Si sabe que el código solo será para un papel, bien, tome atajos. Codifica todo lo que puedas. No pierda tiempo en la validación extensa si el programador es el único que ejecutará el código. Etc. El problema es cuando alguien dice "¡Genial! Ahora utilicemos esto de verdad" o "Ahora utilicemos esto para este escenario completamente diferente de lo que fue desarrollado y probado".

Un desafío relacionado es tener que explicar por qué el software no está listo para el horario de máxima audiencia, aunque obviamente funciona, es decir, es la calidad de un prototipo y no la calidad de producción. ¿Qué quieres decir con que necesitas reescribirlo?

Realmente no tengo mucho más que agregar a lo que ya se ha dicho. Es difícil lograr un equilibrio porque nuestras prioridades son diferentes: la academia tiene que ver con descubrir cosas nuevas, la ingeniería de software tiene más que ver con hacer las cosas de acuerdo con las especificaciones.

Lo más importante que puedo pensar es tratar de liberarme de la cultura del desarrollo interno que se desarrolla en el mundo académico y tratar de mantener un enfoque disciplinado del desarrollo, por muy difícil que sea en muchos casos debido a limitaciones de tiempo. falta de experiencia, etc. Este control-freakery chupa la responsabilidad individual y la toma de decisiones y lo deja en manos de unos pocos que no necesariamente saben mejor

Obtenga un buen libro sobre desarrollo de software, Code Complete ya mencionó que es excelente, así como cualquier libro respetado sobre algoritmos y estructuras de datos. Lea cómo necesitará administrar sus datos, por ejemplo, ¿necesita una búsqueda rápida / tablas hash / árboles binarios? No reinvente la rueda: use las bibliotecas y cosas como STL, de lo contrario, es probable que pierda tiempo. Hay una gran cantidad en la web incluyendo este muy buen blog.

Muchos académicos, además de ser, en ocasiones, primadona y preciados acerca de cualquier enfoque visto como profesional, tienden a ser bastante vagos en sus objetivos. Por decirlo suavemente. Solo por esta razón, es vital construir su propio arsenal de software de funciones y recetas de ayuda, y eventualmente, con suerte, terminará con una especie de marco experimental flexible que le permita probar cualquier combinación de cosas sin estar restringido a ningún problema en particular. zona. Resistir fuertemente la tentación de simplemente sumergirse en el problema en cuestión.

Te cuento mi experiencia.

Es indudable que muchos programas se crean y desperdician en la academia. El hecho es que es difícil adaptar el software de investigación, creado a propósito para un objetivo de investigación específico, a un entorno más general. Además, el producto de la academia son documentos científicos, no software. El valor del software en la academia es cero. Los datos que produce con ese software se evalúan una vez que escriben un documento (lo que requiere mucho tiempo editorial).

En la mayoría de los casos, sin embargo, los grupos de investigación han reconocido patrones frecuentes, que pueden ser pulidos, probados y archivados como conocimiento interno. Esto es lo que hago con mi caja de herramientas personal. Lo cultivo de acuerdo con mis necesidades de investigación, solo con aquellas características que son "proyecto cruzado". Desarrollar un conjunto de herramientas personal es casi un requisito, ya que sus necesidades científicas son probablemente únicas para algunos versos (de lo contrario no estaría investigando) y desea tener la menor cantidad posible de dependencias externas (ya que si algo evoluciona y rompe su cosas, no tendrás tiempo de arreglarlo).

Sin embargo, todo lo demás es demasiado específico para que un proyecto dado se cristalice. Por lo tanto, tiendo a no encapsular algo que es claramente un solucionador de una sola vez. Sin embargo, vuelvo y lo mejoro si, más adelante, otros proyectos requieren el mismo código.

El corto lapso del proyecto y el calor de la investigación (por ejemplo, la visión de publicación o fallecimiento tan central hoy en día) requiere lenguajes ágiles y rápidos y, en general, lenguajes que se pueden comprender rápidamente. Los doctorados en genómica y química cuántica no tienen un fondo de programación formal. En algunos casos, ni siquiera les gusta. Por lo tanto, el lenguaje debe ser rápido, fácil, limpio, flexible y fácil de entender más adelante. El último punto es capital, ya que no hay tiempo para producir documentación, y está garantizado que en el mundo académico, todos se irán, tarde o temprano, quemará la experiencia del grupo a cero cada tres años aproximadamente. La academia es una industria de alto riesgo que despide periódicamente a todos sus ejecutores formados, manteniendo solo algunos administradores. Tener un código que sea mantenible y que pueda ser fácilmente comprendido por otra persona es, por lo tanto, capital. Además, nunca subestimes el poder de una búsqueda de Google para resolver tus problemas. Con un lenguaje bien implementado, es más probable que encuentre respuestas a problemas y problemas en los que pueda tropezar.

La administración también es un problema. La cascada está fuera de discusión. No hay tiempo para la programación del papeleo (requisitos, especificaciones, diseño). Spiral está bastante bien, pero se recomienda claramente el menor papeleo posible. El hecho es que todo lo que no te da un artículo en la academia es una pérdida de tiempo. Si pasa un mes escribiendo especificaciones, es un mes perdido y su contrato expira en 11 meses. Además, ese documento grueso cuenta con cero o casi cero para su carrera (como muchas otras cosas: la administración y la enseñanza son dos ejemplos). Por supuesto, los métodos ágiles también están fuera de discusión. La mayoría del desarrollo lo realizan grupos que están lejos, y en general también tienen muchas otras cosas que hacer. La concentración de la codificación viene en breves ráfagas durante el "tiempo libre" entre artículos, y antes o después de las reuniones. El bazar es el más probable, pero el bazar también conlleva muchos problemas.

Entonces, para responder a su pregunta, la mejor estrategia es la "acumulación lenta" de un buen software conocido, el desarrollo en pequeñas ráfagas con un método y un lenguaje rápidos y ágiles. Las buenas prácticas de codificación deben enseñarse durante las clases, ya que las buenas prácticas de laboratorio se enseñan durante los cursos prácticos (por ejemplo, nunca ponga agua en ácido sulfúrico, siempre lo contrario)