¿Existe una correlación entre algunas prácticas de ingeniería de software y las historias de éxito de ingeniería de software?

He estado leyendo el libro " La caminata del borracho: cómo la aleatoriedad gobierna nuestras vidas " de Leonard Mlodinow y es una lectura realmente esclarecedora. El libro trata las probabilidades y el razonamiento humano. Y digamos, para que conste, que si bien algunas cosas a veces funcionan, existe la posibilidad de que las cosas que creías que funcionaran, no estén relacionadas con lo que realmente lo hizo funcionar.

Las probabilidades no son intuitivas.

Sin embargo, me dio una idea. Ya debería haber estudios sobre esto, que hayan intentado cuantificar los resultados de los esfuerzos de ingeniería de software (que por supuesto es un problema difícil en sí mismo). Y estos estudios deberían señalar qué tipo de prácticas de ingeniería de software son realmente importantes en términos de éxito cuantificable.

es decir

• Un equipo que emplea TDD es thismucho menos probable que tenga thisalgún tipo de problema.
• Un equipo que emplea principios SOLIDOS es thismucho menos probable que tenga thisalgún tipo de problema.
• etcétera etcétera.

Lo que estoy buscando aquí son prácticas de ingeniería de software que muestran una fuerte correlación entre la implementación y el éxito. Estoy seguro de que estas cosas existen pero que son difíciles de encontrar y es por eso que hago esta pregunta.

¿Qué estudios o qué prácticas conoce que tienen una fuerte correlación entre la implementación y el éxito (donde el éxito es algo arbitrario pero creo que entiende la idea)?

Si vamos a vender esa idea de que la ingeniería de software es mejor que la codificación de vaqueros, creo que necesitamos pruebas.

El problema con este tipo de cuantificación es que es casi imposible obtener datos suficientemente buenos sobre la efectividad de las prácticas de ingeniería de software para llegar a una conclusión significativa.

Lo más importante es que la correlación no implica causalidad ; por ejemplo, podría ser que los buenos programadores se apresuren a implementar nuevas ideas rápidamente, por lo que verá una correlación general entre el éxito del proyecto y la adopción de nuevas técnicas de ingeniería de software. Pero eso no prueba nada acerca de la efectividad de las técnicas en sí, ya que todo el efecto podría explicarse por el mayor nivel de talento de los programadores que las adoptan.

Y luego es difícil controlar las variables independientes . ¿Cómo se asegura un experimento justo a menos que pueda controlar todo lo siguiente?

• Experiencia / habilidad / nivel de motivación del equipo
• Alcance real de la adopción de la metodología reclamada (¿realmente están haciendo TDD correctamente?)
• Presencia / ausencia de errores importantes de diseño no relacionados con la metodología de ingeniería de software (por ejemplo, aquellos que requieren una gran arquitectura durante el proyecto)
• Nivel de dificultad de los proyectos que se comparan
• Impacto de los problemas impuestos externamente (por ejemplo, cambios importantes en los requisitos)
• Sesgo de selección (por ejemplo, ¿las personas tienden a compartir datos más a menudo sobre proyectos exitosos?)
• Sesgo de confirmación (por ejemplo, ¿exageraron las personas el éxito de los proyectos que utilizan su metodología favorita?)

Incluso si decide abordar lo anterior dándole a múltiples equipos cuidadosamente seleccionados el mismo problema en las mismas condiciones cuidadosamente controladas, entonces su experimento probablemente sea excesivamente costoso si desea crear suficientes datos para ser estadísticamente significativos.

Y finalmente, es casi imposible medir el éxito :

• Una métrica de cantidad como las líneas de código fuente (SLOC) es terriblemente mala. El incentivo para los desarrolladores es crear monstruosidades de millones de líneas con codificación de copiar / pegar para parecer más "productivo"
• Una métrica a tiempo / dentro del presupuesto depende principalmente del nivel de ambición en las estimaciones utilizadas para crear el plan / presupuesto
• Una métrica de tipo ROI depende tanto de la situación del mercado y de la gestión comercial del producto como de la calidad de la producción de ingeniería (¡mire la historia de Microsoft Windows!)
• Los puntos de historia son útiles para tener una sensación de velocidad en un equipo ágil, pero no son realmente comparables entre equipos
• Las métricas basadas en la funcionalidad, como los puntos de función o los puntos de caso de uso, son quizás los mejores de un grupo malo, pero son burocráticos para recopilar y no reflejan la diferencia en el esfuerzo de ingeniería requerido para crear cada unidad de funcionalidad.
• Las métricas de calidad, como los errores en la producción / disponibilidad de la aplicación, son notoriamente difíciles de calcular y comparar en igualdad de condiciones: depende significativamente de cosas como la plataforma elegida, el tamaño de la base de usuarios y varios factores operativos / de implementación.

En conclusión: tratar de cuantificar el impacto de las tareas de desarrollo de software es una tarea extremadamente difícil, y a pesar de muchos años siguiendo el tema, nadie ha encontrado un enfoque verdaderamente efectivo. Como resultado, la evaluación de las metodologías de desarrollo de software sigue siendo más un arte que una ciencia , y probablemente lo seguirá siendo durante muchos años.

Curiosamente, hay un enfoque que creo que es prometedor: la aplicación de principios lean . Esto no es una panacea y no resolverá directamente el problema de evaluar las metodologías de desarrollo de software, pero tiene una idea clave: un proceso con un elemento particular de desperdicio es inequívocamente menos eficiente que el mismo proceso sin ese elemento de desperdicio, todas las demás cosas son iguales . Entonces, si se enfoca en eliminar el desperdicio en el proceso de desarrollo de software, al menos puede estar seguro de que se está moviendo en la dirección correcta. Además, el desperdicio a menudo es cuantificable, por lo que también debe tener una idea de cuánto más eficiente está siendo, al menos en términos porcentuales aproximados.