Principio de Peter del software

De Wikipedia, la enciclopedia libre
Saltar a: navegación, búsqueda

El principio de Peter del software es usado en ingeniería de software para describir un proyecto moribundo que poco a poco se vuelve demasiado complejo para entenderlo, incluso por sus propios desarrolladores.

En la industria es bien conocido como un asesino silencioso de proyectos, y en el momento en que se presentan los síntomas es a menudo demasiado tarde para hacer algo al respecto. Buenos directores pueden evitar este desastre estableciendo claras prácticas de codificación donde el código y el diseño innecesariamente complicados son evitados.

El nombre se utiliza en el libro C++ FAQs (ver abajo) y es derivado del Principio de Peter — una teoría acerca de la incompetencia en organizaciones jerárquicas. "Los empleados tienden a ascender hasta su nivel de incompetencia".

Causas[editar]

Pérdida de la integridad conceptual[editar]

La integridad conceptual del software es una medida de que tan bien el software se ajusta a un único y simple conjunto de principios de diseño, según The Mythical Man-Month de Fred Brooks. Cuando se hace correctamente, el software proporciona la mayor funcionalidad usando los más simples modismos de programación. Esto hace al software fácil de usar por medio de hacerlo fácil de crear y aprender.

La integridad conceptual se logra cuando el diseño del software procede de un pequeño número de individuos que se ponen de acuerdo. Para que el software mantenga la integridad conceptual, el diseño debe ser controlado por un grupo único y pequeño.

En proyectos sin un fuerte equipo de arquitectura de software, la tarea de diseño es con frecuencia combinada con la tarea de implementación y es implícitamente delegada entre los desarrolladores de software individuales. Bajo estas circunstancias, los desarrolladores son menos propensos a sacrificar sus intereses personales en favor de los intereses del producto. La complejidad del producto crece como resultado de desarrolladores agregando nuevos diseños y alterando los anteriores para reflejar cambios en la moda y sus gustos individuales.

Incompetencia del programador[editar]

Los mejores desarrolladores de software comprenden la importancia de comunicarse con la gente sobre la comunicación con el computador, según el libro Código completo de Steve McConnell. En promedio, el 85 por ciento del tiempo de un programador es dedicado a comunicarse con la gente, mientras que sólo el 15 por ciento se dedica a comunicarse con la computadora. Los programadores de mantenimiento pasan de 50 a 60 por ciento de su tiempo tratando de entender el código que hay que mantener y un programa de software tendrá, en promedio, 10 generaciones de programadores de mantenimiento en su vida.

McConnell afirma que los desarrolladores menos competentes favorecen el código con características avanzada de lenguajes de programación sobre el código que sea legible. El código escrito por estos programadores tiende a aumentar la complejidad del software.

Inexperiencia del programador[editar]

Los programadores inexpertos a veces tomar decisiones de implementación que funcionan pero tienen consecuencias negativas. Los más comunes de estos errores son catalogados y conocidos como hediondeces en el libro Refactorización de Martin Fowler. Con el tiempo, muchos de tales decisiones de implementación degradarán el diseño del software; haciéndolo cada vez más difícil de entender.

Referencias[editar]

  • C++ FAQs by Cline, Lomow, and Girou, Addison-Wesley 1999 ISBN 0-201-30983-1
  • Brooks, F., The Mythical Man Month, Addison-Wesley Longman Inc., 1995.
  • McConnell, S., Code Complete, Microsoft Press, 1993
  • Fowler, M., Refactoring, Addison-Wesley, 2000

Véase también[editar]