Egoless programming: Difference between revisions
Content deleted Content added
→History: RM WP:PEACOCK. |
|||
| (14 intermediate revisions by 11 users not shown) | |||
| Line 1: | Line 1: | ||
{{Short description|Computer development technique}} |
|||
'''Egoless programming''' is a style of [[computer programming]] in which personal factors are minimized so that quality may be improved. The [[cooperative]] methods suggested are similar to those used by other [[collective]] ventures such as [[Wikipedia]]. |
'''Egoless programming''' is a style of [[computer programming]] in which personal factors are minimized so that quality may be improved. The [[cooperative]] methods suggested are similar to those used by other [[collective]] ventures such as [[Wikipedia]]. |
||
==History== |
==History== |
||
The concept was first propounded by [[Gerald M. Weinberg]] in his |
The concept was first propounded by [[Gerald M. Weinberg]] in his 1971 book, ''The Psychology of Computer Programming''.<ref>{{cite book | url=https://books.google.com/books?id=76dIAAAAMAAJ | title=The Psychology of Computer Programming | publisher=Van Nostrand Reinhold | year=1971 | last=Weinberg | first=Gerald M.| isbn=9780442207649 }}</ref> |
||
[[Richard Stallman]] cited egoless programming as the basis for the 2015 [[April Fools Day]] joke announcement for Yellow Hat [[Linux]].<ref>{{cite web|title=Dalai Lama announces Yellow Hat Linux|url=https://www.linux.com/news/dalai-lama-announces-yellow-hat-linux}}</ref> |
|||
==Peer reviews of code== |
==Peer reviews of code== |
||
To ensure quality, reviews of code by other programmers are made. The concept of ''egoless programming'' emphasises that such reviews should be made in a friendly, collegial way in which personal feelings are put aside. [[Software walkthrough|Structured walkthrough]]s are one way of making such a formal review.<ref>{{cite book | url=https://books.google.com/?id=d7BQAAAAMAAJ | title=Peer Reviews in Software: A Practical Guide | publisher=Addison-Wesley | year=2001 | page=14 | isbn= 978-0-201-73485-0 | last=Wiegers | first=Karl Eugene}}</ref> |
To ensure quality, reviews of code by other programmers are made. The concept of ''egoless programming'' emphasises that such reviews should be made in a friendly, collegial way in which personal feelings are put aside. [[Software walkthrough|Structured walkthrough]]s are one way of making such a formal review.<ref>{{cite book | url=https://books.google.com/books?id=d7BQAAAAMAAJ | title=Peer Reviews in Software: A Practical Guide | publisher=Addison-Wesley | year=2001 | page=14 | isbn= 978-0-201-73485-0 | last=Wiegers | first=Karl Eugene}}</ref> |
||
==Strengths== |
==Strengths== |
||
| Line 16: | Line 15: | ||
==Weaknesses== |
==Weaknesses== |
||
* Projects take |
* Projects take longer to complete.<ref name="mantei1981">{{cite journal | url=http://sunnyday.mit.edu/16.355/mantei-teams.pdf | title=The Effect of Programming Team Structures on Programming Tasks | last=Mantei | journal=Communications of the ACM |date=March 1981 | volume=24 | issue=3 | pages=106–113 | first=Marilyn | doi=10.1145/358568.358571| s2cid=207907944 }}</ref> |
||
* Projects experience a higher failure rate due to the decentralized nature of and volume of communication between members of the team.<ref name="mantei1981">{{cite journal | url=http://sunnyday.mit.edu/16.355/mantei-teams.pdf | title=The Effect of Programming Team Structures on Programming Tasks | last=Mantei | journal=Communications of the ACM |date=March 1981 | volume=24 | issue=3 | pages=106–113 | first=Marilyn | doi=10.1145/358568.358571}}</ref> |
* Projects experience a higher failure rate due to the decentralized nature of and volume of communication between members of the team.<ref name="mantei1981">{{cite journal | url=http://sunnyday.mit.edu/16.355/mantei-teams.pdf | title=The Effect of Programming Team Structures on Programming Tasks | last=Mantei | journal=Communications of the ACM |date=March 1981 | volume=24 | issue=3 | pages=106–113 | first=Marilyn | doi=10.1145/358568.358571| s2cid=207907944 }}</ref> |
||
* Risky shift phenomenon{{snd}} Programmers attempt riskier solutions to solve a software problem.<ref name="mantei1981">{{cite journal | url=http://sunnyday.mit.edu/16.355/mantei-teams.pdf | title=The Effect of Programming Team Structures on Programming Tasks | last=Mantei | journal=Communications of the ACM |date=March 1981 | volume=24 | issue=3 | pages=106–113 | first=Marilyn | doi=10.1145/358568.358571}}</ref> |
* Risky shift phenomenon{{snd}} Programmers attempt riskier solutions to solve a software problem.<ref name="mantei1981">{{cite journal | url=http://sunnyday.mit.edu/16.355/mantei-teams.pdf | title=The Effect of Programming Team Structures on Programming Tasks | last=Mantei | journal=Communications of the ACM |date=March 1981 | volume=24 | issue=3 | pages=106–113 | first=Marilyn | doi=10.1145/358568.358571| s2cid=207907944 }}</ref> |
||
* Simple tasks are made more difficult by open communication channels.{{citation needed|date=June 2014}} |
* Simple tasks are made more difficult by open communication channels.{{Clarify|date=February 2020}}{{citation needed|date=June 2014}} |
||
==Rival concepts== |
==Rival concepts== |
||
| Line 25: | Line 24: | ||
==See also== |
==See also== |
||
* [[List of software development philosophies]] |
|||
| ⚫ | |||
*[[Software review]] |
|||
| ⚫ | |||
==References== |
==References== |
||
Latest revision as of 00:08, 9 November 2024
Egoless programming is a style of computer programming in which personal factors are minimized so that quality may be improved. The cooperative methods suggested are similar to those used by other collective ventures such as Wikipedia.
History
[edit]The concept was first propounded by Gerald M. Weinberg in his 1971 book, The Psychology of Computer Programming.[1]
Peer reviews of code
[edit]To ensure quality, reviews of code by other programmers are made. The concept of egoless programming emphasises that such reviews should be made in a friendly, collegial way in which personal feelings are put aside. Structured walkthroughs are one way of making such a formal review.[2]
Strengths
[edit]- Works best for complex tasks.
- Open communication channels allow information to flow freely to team members
- Greater conformity that helps in consistent documentation
- Team members have greater job satisfaction.[3]
Weaknesses
[edit]- Projects take longer to complete.[3]
- Projects experience a higher failure rate due to the decentralized nature of and volume of communication between members of the team.[3]
- Risky shift phenomenon – Programmers attempt riskier solutions to solve a software problem.[3]
- Simple tasks are made more difficult by open communication channels.[clarification needed][citation needed]
Rival concepts
[edit]Egoless programming explicitly minimizes constraints of hierarchy and status so as to enable the free exchange of ideas and improvements. It may be contrasted with the chief programmer team concept which emphasises specialisation and leadership in teams so that they work in a more disciplined way.[4]
See also
[edit]References
[edit]- ^ Weinberg, Gerald M. (1971). The Psychology of Computer Programming. Van Nostrand Reinhold. ISBN 9780442207649.
- ^ Wiegers, Karl Eugene (2001). Peer Reviews in Software: A Practical Guide. Addison-Wesley. p. 14. ISBN 978-0-201-73485-0.
- ^ a b c d Mantei, Marilyn (March 1981). "The Effect of Programming Team Structures on Programming Tasks" (PDF). Communications of the ACM. 24 (3): 106–113. doi:10.1145/358568.358571. S2CID 207907944.
- ^ Grubb, Penny; Takang, Armstrong A. (2003), Software maintenance: concepts and practice, World Scientific, ISBN 978-981-238-426-3