Hispanopedia WikiEl principio de Software Peter se utiliza en la ingeniería de software para describir un proyecto moribundo que se ha vuelto demasiado complejo como para ser comprendido incluso por sus propios desarrolladores.
En el sector, se sabe que es un asesino silencioso de proyectos, pero cuando aparecen los síntomas, suele ser demasiado tarde para solucionarlo. Los buenos gestores pueden evitar este desastre estableciendo prácticas de codificación claras que eviten el código y el diseño innecesariamente complicados.
El nombre se utiliza en el libro Preguntas frecuentes sobre C++ (véase más abajo) y deriva del principio de Peter , una teoría sobre la incompetencia en las organizaciones jerárquicas.
Causas
Pérdida de integridad conceptual
La integridad conceptual del software es una medida de qué tan bien se ajusta a un conjunto único y simple de principios de diseño , según The Mythical Man Month . [ 1 ] Cuando se hace correctamente, proporciona la mayor funcionalidad usando los modismos más simples . Hace que el software sea más fácil de usar al hacer que sea simple de crear y aprender .
La integridad conceptual se logra cuando el diseño del software procede de un pequeño grupo de personas que coinciden en el propósito del proyecto . Para que el software mantenga la integridad conceptual, el diseño debe ser controlado por un único y pequeño grupo de personas que comprendan el código en profundidad (incluida la naturaleza de cómo interactúan todas las subrutinas y variables) .
En proyectos sin un equipo de arquitectura de software sólido , la tarea de diseño suele combinarse con la de implementación y se delega implícitamente entre los desarrolladores . En estas circunstancias, es menos probable que los desarrolladores sacrifiquen sus intereses personales en favor del producto . La complejidad del producto aumenta como resultado de que los desarrolladores añaden nuevos diseños y modifican los anteriores para reflejar los cambios en las tendencias y los gustos individuales .
Incompetencia del programador
Según Code Complete , los buenos desarrolladores de software comprenden la importancia de comunicarse con las personas por encima de comunicarse con la computadora. [ 2 ] Los estudios mostraron que los programadores dedican más del 50 % de su tiempo a comunicarse con las personas, mientras que la programación propiamente dicha puede ocupar tan solo entre el 15 % y el 10 %, dependiendo del nivel de antigüedad. [ 3 ] [ 4 ] [ 5 ] [ 6 ]
Los programadores de mantenimiento dedican entre el 50 y el 60 por ciento de su tiempo a intentar comprender el código que tienen que mantener, y un programa de software tendrá, de media, 10 generaciones de programadores de mantenimiento a lo largo de su vida útil .
Inexperiencia en programación
En ocasiones, los programadores toman decisiones de implementación que funcionan, pero que tienen consecuencias negativas imprevistas. Los errores más comunes se catalogan y se denominan " malos olores" en el libro Refactoring . [ 7 ] Con el tiempo, muchas de estas decisiones de implementación degradan el diseño del software, lo que dificulta cada vez más su comprensión.
Véase también
- Antipatrón : solución a un problema que puede ser de uso común pero que generalmente es una mala elección .
- Marcha de la muerte (gestión de proyectos) – Término de gestión de proyectos
- La décima regla de Greenspun : aforismo informático
- Gestión de proyectos : práctica de dirigir el trabajo de un equipo para lograr objetivos y criterios en un momento determinado.
- Proceso de desarrollo de software : proceso mediante el cual se desarrolla el software.
- Ofuscación (software) : Creación deliberada de código difícil de entender.
Referencias
- ↑ Brooks 2013 .
- ↑ McConnell 2004 .
- ^ Sullivan 1988 , págs. 2-5.
- ↑ The Workplace Stack Exchange 2022 .
- ↑ Rodenas 2022 .
- ↑ Gramos 2019 .
- ↑ Fowler y Beck 2013 .
Literatura
- Brooks, Frederick P. (2013). El mítico mes-hombre: ensayos sobre ingeniería de software (Edición de aniversario con 4 capítulos nuevos, 39.ª reimpresión ). Boston, Mass.: Addison-Wesley. ISBN 9780201835953.
- Cline, Marshall P.; Lomow, Greg A.; Girou, Mike (2010). Preguntas frecuentes sobre C++ (2.ª ed.). Reading, Mass.: Addison-Wesley. ISBN 978-0-201-30983-6.
- Fowler, Martin ; Beck, Kent (2013). Refactoring: improving the design of existing code (28.ª ed. impresa). Boston: Addison-Wesley. ISBN 978-0201485677.
- Grams, Chris (15 de octubre de 2019). "¿Cuánto tiempo dedican los desarrolladores a escribir código?" . The New Stack . Recuperado el 5 de diciembre de 2023 .
- McConnell, Steve (2004). Código completo (2.ª ed.). Redmond, Washington: Microsoft Press. ISBN 0735619670.
- Rodenas, David (21 de octubre de 2022). "Los desarrolladores dedican menos del 10 % de su tiempo a programar" . Medium . Recuperado el 5 de diciembre de 2023 .
- Sullivan, SL (1988). "¿Cuánto tiempo dedican los profesionales del software a comunicarse?" . ACM SIGCPR Computer Personnel . 11 (4): 2– 5. doi : 10.1145/54127.54128 . ISSN 0160-2497 .
- "Desarrolladores de software: ¿cuánto tiempo dedican realmente a escribir código en comparación con otras tareas laborales?" . The Workplace Stack Exchange . 21/03/2022 . Consultado el 05/12/2023 .
- Refranes
- Gestión de proyectos de software