Software Peter principle
{{Short description|Engineering term for a complex, failing project}}
{{multiple issues|
{{more footnotes|date=August 2011}}
{{Original research|date=October 2019}}
}}
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|date=July 2015}} 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|date=July 2015}} 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
=Loss of conceptual integrity=
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.{{sfn|Brooks|2013}} 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|date=July 2015}}.
Conceptual integrity is achieved when the software’s design proceeds from a small number of agreeing individuals{{citation needed|date=July 2015}}. 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|date=October 2022}}.
In projects without a strong software architecture team, the task of design is often {{weasel inline|date=October 2022}} combined with the task of implementation and is implicitly delegated among the individual software developers {{citation needed|date=October 2022}}. Under these circumstances, developers are less likely to sacrifice personal interests in favor of the interests of the product{{citation needed|date=October 2022}}. 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|date=October 2022}}.
=Programmer incompetence=
Good software developers understand the importance of communicating with people over communicating with the computer, according to Code Complete.{{sfn|McConnell|2004}} 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.{{sfn | Sullivan | 1988 | pp=2–5}}{{sfn | The Workplace Stack Exchange | 2022}}{{sfn | Rodenas | 2022}}{{sfn | Grams | 2019}}
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|date=October 2022}}.
=Programmer inexperience=
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.{{sfn|Fowler|Beck|2013}} Over time, many such implementation choices degrade the software’s design, making it increasingly difficult to understand.
See also
- {{annotated link|Anti-pattern}}s
- {{annotated link|Death march (project management)}}
- {{annotated link|Greenspun's tenth rule}}
- {{annotated link|Project management}}
- {{annotated link|Software development process}}
- {{annotated link|Obfuscation (software)}}
References
{{reflist}}
Literature
- {{cite book |last1=Brooks |first1=Frederick P. |authorlink=Frederick P. Brooks|title=The mythical man-month: essays on software engineering |date=2013 |publisher=Addison-Wesley |location=Boston, Mass. |isbn=9780201835953 |edition=Anniversary with 4 new chapters, 39. printing}}
- {{cite book |last1=Cline |first1=Marshall P. |last2=Lomow |first2=Greg A. |last3=Girou |first3=Mike |title=C++ FAQs |date=2010 |publisher=Addison-Wesley |location=Reading, Mass. |isbn=978-0-201-30983-6 |edition=2nd}}
- {{cite book |last1=Fowler |first1=Martin |authorlink1=Martin Fowler (software engineer)|last2=Beck |first2=Kent |title=Refactoring: improving the design of existing code |date=2013 |publisher=Addison-Wesley |location=Boston |isbn=978-0201485677 |edition=28. printing}}
- {{cite web | last=Grams | first=Chris | title=How Much Time Do Developers Spend Actually Writing Code? | website=The New Stack | date=2019-10-15 | url=https://thenewstack.io/how-much-time-do-developers-spend-actually-writing-code/ | access-date=2023-12-05}}
- {{cite book |last1=McConnell |first1=Steve |authorlink1=Steve McConnell|title=Code complete |date=2004 |publisher=Microsoft Press |location=Redmond, Washington |isbn=0735619670 |edition=2nd}}
- {{cite web | last=Rodenas | first=David | title=Developers Spend Less Than 10% of Time Coding | website=Medium | date=2022-10-21 | url=https://drpicox.medium.com/developers-spend-less-than-10-of-time-coding-51c36c73a93b | access-date=2023-12-05}}
- {{cite journal | last=Sullivan | first=S. L. | title=How much time do software professionals spend communicating? | journal=ACM SIGCPR Computer Personnel | volume=11 | issue=4 | date=1988 | issn=0160-2497 | doi=10.1145/54127.54128 | pages=2–5| doi-access=free }}
- {{cite web | title=Software developers: how much time do you actually spend actually writing code compared with other tasks at work? | website=The Workplace Stack Exchange | date=2022-03-21 | url=https://workplace.stackexchange.com/questions/183520/software-developers-how-much-time-do-you-actually-spend-actually-writing-code-c | access-date=2023-12-05 | ref={{sfnref | The Workplace Stack Exchange | 2022}}}}