egoless programming

The concept was first propounded by Gerald M. Weinberg in his 1971 book, The Psychology of Computer Programming.{{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 }}

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.{{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}}

• Works best for complex tasks. ('difficult' used in )
• Open communication channels allow information to flow freely to team members
• Greater conformity that helps in consistent documentation
• Team members have greater job satisfaction.

• Projects take longer to complete.{{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 }}
• Projects experience a higher failure rate due to the decentralized nature of and volume of communication between members of the team.{{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 }}
• Risky shift phenomenon{{snd}} Programmers attempt riskier solutions to solve a software problem.{{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 }}
• Simple tasks are made more difficult by open communication channels.{{Clarify|date=February 2020}}{{citation needed|date=June 2014}}

Note: The single paper cited for 'Strengths & Weaknesses' is from 1981 and says in its conclusions:

Most of the research on group problem-solving behavior was conducted in a laboratory setting with students and tasks of short duration.

None of these task/structure recommendations have been tested in a software development environment.

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.{{Citation | url=https://books.google.com/books?id=ge8o_VkAsiYC&pg=PA210 | title=Software maintenance: concepts and practice | publisher=World Scientific | year=2003 | isbn=978-981-238-426-3 | last1=Grubb | first1=Penny | last2=Takang | first2=Armstrong A.}}

• List of software development philosophies
• Software review
• Egolessness

{{reflist}}

• [http://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/ The Ten Commandments of Egoless Programming]

{{DEFAULTSORT:Egoless Programming}}

Category:Software development process