Egoless programming: Difference between revisions
m CiteCompletion, dates: 1, works/pubs: 1, ISBNs: 2, using AWB |
addition to existing article |
||
| Line 8: | Line 8: | ||
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, collegiate 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=http://books.google.com/books?id=d7BQAAAAMAAJ&pgis=1|page=14|title=Peer Reviews in Software: A Practical Guide|author=Karl Eugene Wiegers|ibn=0201734850|year=2001|publisher=Addison-Wesley | isbn=9780201734850}}</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, collegiate 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=http://books.google.com/books?id=d7BQAAAAMAAJ&pgis=1|page=14|title=Peer Reviews in Software: A Practical Guide|author=Karl Eugene Wiegers|ibn=0201734850|year=2001|publisher=Addison-Wesley | isbn=9780201734850}}</ref> |
||
==Strengths== |
|||
*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<ref>http://sunnyday.mit.edu/16.355/mantei-teams.pdf</ref> |
|||
==Weaknesses== |
|||
*projects take a longer time to complete |
|||
*risky shift phenomenon - programmers attempt riskier solutions to solve a software problem<ref>http://sunnyday.mit.edu/16.355/mantei-teams.pdf</ref> |
|||
*simple tasks made more difficult by open communication channels |
|||
==Rival concepts== |
==Rival concepts== |
||
Revision as of 05:55, 17 February 2011
Egoless programming is a style of computer programming in which personal factors are minimised so that quality may be improved. The cooperative methods suggested are similar to those used by other collective ventures such as Wikipedia.
Origin
The concept was first propounded by Jerry Weinberg in his seminal book, The Psychology of Computer Programming.[1]
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, collegiate way in which personal feelings are put aside. Structured walkthroughs are one way of making such a formal review.[2]
Strengths
- 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
- projects take a longer time to complete
- risky shift phenomenon - programmers attempt riskier solutions to solve a software problem[4]
- simple tasks made more difficult by open communication channels
Rival concepts
Egoless programming explicitly minimises 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.[5]
See also
References
- ^ Gerald M. Weinberg (1971). The Psychology of Computer Programming. Van Nostrand Reinhold.
- ^ Karl Eugene Wiegers (2001). Peer Reviews in Software: A Practical Guide. Addison-Wesley. p. 14. ISBN 9780201734850.
{{cite book}}: Unknown parameter|ibn=ignored (help) - ^ http://sunnyday.mit.edu/16.355/mantei-teams.pdf
- ^ http://sunnyday.mit.edu/16.355/mantei-teams.pdf
- ^ Penny Grubb, Armstrong A. Takang (2003), Software maintenance: concepts and practice, World Scientific, ISBN 9789812384263