The Software Peter principle is used in software engineering to describe a dying project which has become too complex to be understood even by its own developers.
It is well known in the industry[citation needed] as a silent killer of projects, but by the time the symptoms arise it is often too late to do anything about it[citation needed]. Good managers can avoid this disaster by establishing clear coding practices where unnecessarily complicated code and design is avoided.
The name is used in the book C++ FAQs (see below), and is derived from the Peter principle – a theory about incompetence in hierarchical organizations.
The conceptual integrity of software is a measure of how well it conforms to a single, simple set of design principles, according to The Mythical Man Month.[1] When done properly, it provides the most functionality using the simplest idioms. It makes software easier to use by making it simple to create and learn[citation needed].
Conceptual integrity is achieved when the software’s design proceeds from a small number of agreeing individuals[citation needed]. For software to maintain conceptual integrity, the design must be controlled by a single, small group of people who understand the code (including the nature of how all the subroutines and variables interact) in depth[citation needed].
In projects without a strong software architecture team, the task of design is often[weasel words] combined with the task of implementation and is implicitly delegated among the individual software developers[citation needed]. Under these circumstances, developers are less likely to sacrifice personal interests in favor of the interests of the product[citation needed]. The complexity of the product grows as a result of developers adding new designs and altering earlier ones to reflect changes in fashion and individual taste[citation needed].
Good software developers understand the importance of communicating with people over communicating with the computer, according to Code Complete.[2] Studies showed that programmers spends more than 50% of their time communicating with people, while the actual programming may only take up as little as 15% to 10%, depending on the level of seniority.[3][4][5][6]
Maintenance programmers spend 50 to 60 percent of their time trying to understand the code they have to maintain and a software program will have, on average, 10 generations of maintenance programmers in its lifetime[citation needed].
Programmers sometimes make implementation choices that work but have unintended negative consequences. The most common of these mistakes are cataloged and referred to as smells in the book Refactoring.[7] Over time, many such implementation choices degrade the software’s design, making it increasingly difficult to understand.