Software Peter principle
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
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]- Anti-pattern – Common response to a recurring problem that is usually ineffective or counterproductives
- Death march (project management) – Project management term
- Greenspun's tenth rule – Computing aphorism
- Project management – Practice of leading the work of a team to achieve goals and criteria at a specified time
- Software development process – Process by which software is developed
- Obfuscation (software) – Deliberate creation of difficult-to-understand code
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.