Jump to content

Software Peter principle

From Wikipedia, the free encyclopedia

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.

Causes

[edit]

Loss of conceptual integrity

[edit]

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].

Programmer incompetence

[edit]

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].

Programmer inexperience

[edit]

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.

See also

[edit]

References

[edit]

Literature

[edit]
  • Brooks, Frederick P. (2013). The mythical man-month: essays on software engineering (Anniversary with 4 new chapters, 39. printing ed.). Boston, Mass.: Addison-Wesley. ISBN 9780201835953.
  • Cline, Marshall P.; Lomow, Greg A.; Girou, Mike (2010). C++ FAQs (2nd ed.). Reading, Mass.: Addison-Wesley. ISBN 978-0-201-30983-6.
  • Fowler, Martin; Beck, Kent (2013). Refactoring: improving the design of existing code (28. printing ed.). Boston: Addison-Wesley. ISBN 978-0201485677.
  • Grams, Chris (2019-10-15). "How Much Time Do Developers Spend Actually Writing Code?". The New Stack. Retrieved 2023-12-05.
  • McConnell, Steve (2004). Code complete (2nd ed.). Redmond, Washington: Microsoft Press. ISBN 0735619670.
  • Rodenas, David (2022-10-21). "Developers Spend Less Than 10% of Time Coding". Medium. Retrieved 2023-12-05.
  • Sullivan, S. L. (1988). "How much time do software professionals spend communicating?". ACM SIGCPR Computer Personnel. 11 (4): 2–5. doi:10.1145/54127.54128. ISSN 0160-2497.
  • "Software developers: how much time do you actually spend actually writing code compared with other tasks at work?". The Workplace Stack Exchange. 2022-03-21. Retrieved 2023-12-05.
[edit]