Egoless programming: Difference between revisions

Revision as of 07:57, 20 June 2014

Latest revision as of 04:56, 26 March 2025

(38 intermediate revisions by 30 users not shown)

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]].

== Origin History==

The concept was first propounded by [[Gerald Weinberg|JerryM. Weinberg]] in his seminal1971 book, ''The Psychology of Computer Programming''.<ref>{{cite book | url=httphttps://books.google.co.ukcom/books?id=76dIAAAAMAAJ&pgis=1 | title=The Psychology of Computer Programming | publisher=Van Nostrand Reinhold | year=1971 | last=Weinberg | first=Gerald M.| isbn=9780442207649 }}</ref>

The concept was first propounded by [[Gerald Weinberg|Jerry Weinberg]] in his seminal book, ''The Psychology of Computer Programming''.<ref>{{cite book | url=http://books.google.co.uk/books?id=76dIAAAAMAAJ&pgis=1 | title=The Psychology of Computer Programming | publisher=Van Nostrand Reinhold | year=1971 | last=Weinberg | first=Gerald M.}}</ref>

==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, collegiatecollegial 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=httphttps://books.google.com/books?id=d7BQAAAAMAAJ&pgis=1 | title=Peer Reviews in Software: A Practical Guide | publisher=Addison-Wesley | isbn=0201734850 | 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, 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 | title=Peer Reviews in Software: A Practical Guide | publisher=Addison-Wesley | isbn=0201734850 | year=2001 | page=14 | isbn=978-0-201-73485-0 | last=Wiegers | first=Karl Eugene}}</ref>

==Strengths==

*works Works best for complex tasks. ('difficult' used in <ref name="mantei1981"/>)

*open Open communication channels allow information to flow freely to team members

*greater Greater conformity that helps in consistent documentation

*team Team members have greater job satisfaction.<ref name="mantei1981"/>

==Weaknesses==

* 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 take a longer time to complete{{citation needed}}

*risky shiftProjects phenomenonexperience -a programmershigher attemptfailure riskierrate solutionsdue to solvethe adecentralized softwarenature problemof 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| s2cid=207907944 }}</ref>

*simple Simple tasks are made more difficult by open communication channels.{{Clarify|date=February 2020}}{{citation needed|date=June 2014}}

Note: The single paper cited <ref name="mantei1981"/> for 'Strengths & Weaknesses' is from 1981 and says in its conclusions:

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

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

==Rival concepts==

Egoless programming explicitly minimizes constraints of [[hierarchy]] and [[Social status|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.<ref>{{Citation | url=httphttps://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.}}</ref>

==See also==

* [[List of software development philosophies]]

* [[Egolessness]]

*[[Software review]]

* [[Egolessness]]

==References==

Line 30 ⟶ 39:

==External links==

*[http://archiveblog.is/20130102090646/http://articles.techrepublic.comcodinghorror.com/5100the-10878_11ten-1045782.htmlcommandments-of-egoless-programming/ The Ten Commandments of Egoless Programming]

{{DEFAULTSORT:Egoless Programming}}