Hace unos días, hablando de libros, salió el “Facts and Fallacies of Software Engineering” de Glass, del que dije que me pareció tan bueno como para dedicarle un post.
El libro de R. Glass, de apenas 220 páginas, expone un conjunto de verdades, poco conocidas, del desarrollo software y un conjunto (menor) de falacias (aún creídas y secundadas por muchos).
Y para que te hagas una buena idea de lo que trata, he traducido cada una de las verdades y mentiras que enumera el libro:
Verdades sobre personas
1. El factor más importante en el software es la calidad de los programadores (un post relacionado).
2. Los mejores programadores son hasta 28 veces mejores que los peores.
3. Añadir personas a un proyecto retrasado lo retrasa más (un post sobre este punto).
4. El entorno de trabajo tiene profundo impacto en la productividad y la calidad (post relacionado).
Verdades sobre herramientas
5. Exagerar sobre herramientas y tecnología es una plaga en software.
6. Las nuevas herramientas y técnicas causan una pérdida inicial de la productividad / calidad.
7. Los desarrolladores de software hablan mucho sobre herramientas, pero rara vez las utilizan.
Verdades sobre estimación
8. Una de las dos causas más comunes de perdida de control de un proyectos es la pobre estimación.
9. Estimación de software normalmente se realiza en el momento equivocado.
10. Estimación de software la hace, generalmente, gente equivocada.
11. Las estimaciones software rara vez se corrigen a medida que avanza el proyecto.
12. No es sorprendente que las estimaciones de software sean malas.
13. Hay una desconexión entre la gestión y los programadores.
14. La respuesta a un estudio de viabilidad es casi siempre «sí».
Verdades sobre reutilización
15. Reutilizaciones pequeñas son un problema resuelto.
16. Reutilizaciones grandes siguen siendo un problema sin resolver en su mayoría.
17. Componentes reutilizables son tres veces más difíciles de construir y deberían ser probados en tres escenarios diferentes.
18. Modificar código reutilizado es particularmente propenso a errores.
19. Patrones de reutilización son una solución a los problemas de reutilización de código.
Verdades sobre diseño
20. Rara vez hay una mejor solución de diseño a un problema de software.
21. El diseño es un complejo proceso iterativo. Soluciones de diseño iniciales suelen ser estar equivocadas y ciertamente no son óptimas.
Verdades sobre programación
22. Las «primitivas» de diseño rara vez coinciden con las «primitivas» de programación.
23. COBOL es un lenguaje malo, pero todos los demás son mucho peores.
Verdades sobre eliminar errores
24. La eliminación de errores es la fase que más tiempo consume en el ciclo de vida.
Verdades sobre pruebas
25. El software, por lo general, se prueba con un nivel de cobertura del 55 al 60 %.
26. Una cobertura de pruebas al 100% es demasiado difícil (post sobre este punto).
27. Las herramientas para pruebas son esenciales, pero rara vez se utilizan.
28. La automatización de pruebas raramente lo es. La mayoría de las actividades de prueba no se pueden automatizar.
29. El «debug code» es un importante complemento a las herramientas de prueba.
Verdades sobre revisión e inspección
30. Inspecciones rigurosas pueden eliminar hasta el 90% de los errores antes de que se ejecute el primer caso de prueba.
31. Las inspecciones rigurosas no deben sustituir a las pruebas.
Verdades sobre mantenimiento
32. Mantenimiento consume típicamente del 40 al 80 % de los costes del software. Es probable que sea la fase más importante del ciclo de vida del software.
33. El mantenimiento es una solución, no un problema.
34. Entender el producto existente es la tarea de mantenimiento más difícil.
35. Mejores métodos conducen a un mayor mantenimiento, no menos.
Verdades sobre calidad
36. La calidad es una colección de atributos.
37. La calidad no es la satisfacción del usuario, la entrega dentro del presupuesto, en tiempo o la fiabilidad.
Verdades sobre fiabilidad
38. Hay errores que la mayoría de los programadores tienden a hacer.
39. Los errores suelen agruparse.
40. No hay un único mejor enfoque para la eliminación de errores de software.
41. Los errores residuales siempre persistirán. El objetivo debe ser reducir al mínimo, o eliminar, los errores graves.
Verdades sobre eficiencia
42. La eficiencia surge más de un buen diseño que de una buena codificación.
Y las falacias…
43. No se puede gestionar lo que no se puede medir.
44. Puedes gestionar la calidad en un producto de software.
45. La programación puede y debe ser sin ego (discutible).
46. El software necesita más metodologías.
47. Para estimar costes y calendario, primero hay que estimar las líneas de código.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
De acuerdo… al 98%
sólo discutiría la:
44. Puedes gestionar la calidad en un producto de software.
Y lo haré porque me parece una dimensión tan importante (y olvidada), que no debe quedar sin gestión, en mi opinión, porque se enuncie como no gestionable. Si no será el saco roto por el que ajustar los proyectos para que entren en la Triple Restricción (Tiempo, Dinero, Alcance) olvidando que el Alcance (digamos funcional) sin la Calidad adecuada puede acabar generando un producto inválido.
Si existen factores de calidad y técnicas para medir o elevar unos u otros factores… yo creo que tenemos herramientas para gestionarla.
Lo malo es que algunos factores son opuestos y por tanto la máxima calidad para todos los escenarios/usuarios/clientes no existirá; pero de ahí a que no se pueda gestionar, va un trecho.