This dissertation is original in using the contrasting ideas of two leading 20th century philosophers of science, Karl Popper and Thomas Kuhn, to provide a philosophical understanding, firstly, of the shift from traditional software methodologies to the so-called Agile methodologies, and, secondly, of the values, principles and practices underlying the most prominent of the Agile methodologies, Extreme Programming (XP). This dissertation will take a revisionist approach, following Fuller—the founder of social epistemology—in reading Popper against Kuhn's epistemological hegemony. The investigations in this dissertation relate to two main branches of philosophy— epistemology and ethics. The epistemological part of this dissertation compares both Kuhn and Popper's alternative ideas of the development of scientific knowledge to the Agile methodologists' ideas of the development of software, in order to assess the extent to which Agile software development resembles a scientific discipline. The investigations relating to ethics in this dissertation transfer concepts from social engineering—in particular, Popper's distinction between piecemeal and utopian social engineering—to software engineering, in order to assess both the democratic and authoritarian aspects of Agile software development and management. The use of Kuhn's ideas of scientific revolutions and paradigm shift by several leading figures of the Agile software methodologies—most notably, Kent Beck, the leader of the most prominent Agile software methodology, Extreme Programming (XP)—to predict a fundamental shift from traditional to Agile software methodologies, is critically assessed in this dissertation. A systematic investigation into whether Kuhn's theory as a whole, can provide an adequate account of the day-to-day practice of Agile software development is also provided. As an alternative to the use of Kuhn's ideas, the critical rationalist philosophy of Karl Popper is investigated. On the one hand, this dissertation assesses whether the epistemological aspects of Popper's philosophy—especially his notions of falsificationism, evolutionary epistemology, and three worlds metaphysics—provide a suitable framework for understanding the philosophical basis of everyday Agile software development. On the other hand, the aspects of Popper's philosophy relating to ethics, which provide an ideal for scientific practice in an open society, are investigated in order to determine whether they coincide with the avowedly democratic values of Agile software methodologies. The investigations in this dissertation led to the following conclusions. Firstly, Kuhn's ideas are useful in predicting the effects of the full-scale adoption of Agile methodologies, and they describe the way in which several leaders of the Agile methodologies promote their methodologies; they do not, however, account for the detailed methodological practice of Agile software development. Secondly, several aspects of Popper's philosophy, were found to be aligned with several aspects of Agile software development. In relation to epistemology, Popper's principle of falsificationism provides a criterion for understanding the rational and scientific basis of several Agile principles and practices, his evolutionary epistemology resembles the iterative-incremental design approach of Agile methodologies, and his three worlds metaphysical model provides an understanding of both the nature of software, and the approach advocated by the Agile methodologists' of creating and sharing knowledge. In relation to ethics, Popper's notion of an open society provides an understanding of the rational and ethical basis of the values underlying Agile software development and management, as well as the piecemeal adoption of Agile software methodologies. / Dissertation (MSc)--University of Pretoria, 2009. / Computer Science / unrestricted

När en grupp utvecklare jobbar med samma kodbas kan konflikter uppstå med avseende på implementationen av moduler eller delsystem som varje utvecklare individuellt jobbar på. Dessa konflikter måste snabbt lösas för att projektet ska fortskrida och inte stagnera. Utvecklare som sällan kommunicerar framför ofta okompatibla moduler eller delsystem som kan vara svåra eller omöjliga att integrera i kodbasen, detta leder ofta till s.k. “integration hell” där det kan ta väldigt lång tid att anpassa ny kod till en befintlig kodbas.En strategi som man kan ta till är “continuous integration”, ett arbetssätt som erbjuder en rad fördelar när man jobbar i grupp på en gemensam kodbas. Continuous integration är möjligt att tillämpa utan verktyg eftersom detta är ett arbetssätt. Däremot kan processen stödjas av ett s.k. “CI-system” som är något av en teknisk implementation eller påtagligt införlivande och stöd för arbetsmetoden “continuous integration”.Denna rapport syftar till att ge en inblick i vad ett CI-system är och vad den principiellt består av. Vi undersöker vad ett CI-system absolut måste bestå av genom en litteraturundersökning och en marknadsundersökning. Vi ställer upp dessa beståndsdelar som “funktionella” och “icke-funktionella” krav för ett typiskt CI-system. Vi kan på så vis kvantifiera och kategorisera olika komponenter och funktionaliteter som bör innefattas i ett typiskt CI-system. I denna rapport finns även ett bihang som visar hur man kommer igång med att bygga en egen CI-server mha. CI-systemmjukvaran “TeamCity”.Slutsatsen av vår rapport är att CI-system är ett viktigt redskap som kan underlätta mjukvaruutveckling. Med hjälp av CI-system kan man stödja utvecklingsprocessen genom att bl.a. förhindra integrationsproblem, automatisera vissa delar av arbetsprocessen (kompilering av källkod, testning av mjukvara, notifikation om stabilitet av kodbas och distribution av färdig mjukvara) samt snabbt hitta och lösa integrationsfel. / When a group of developers work on the same code base, conflicts may arise regarding the implementation of modules or subsystems that developers individually work on. These conflicts have to be resolved quickly in order for the project to advance at a steady pace. Developers who do not communicate changes or other necessary deviations may find themselves in a situation where new or modified modules or subsystems are impossible or very difficult to integrate into the mainline code-base. This often leads to so called “integration hell” where it could take huge amounts of time to adapt new code into the current state of the code-base. One strategy, which can be deployed to counteract this trend is called “continuous integration”. This practice offers a wide range of advantages when a group of developers collaborates on writing clean and stable code. Continuous integration can be put into practice without the use of any tools as it is a “way to do things” rather than an actual tool. With that said, it is possible to support the practice with a tangible tool called a CI-system.This study aims to give insight into the makings of a CI-system and what it fundamentally consists of and has to be able to do. A study of contemporary research reports regarding the subject and a survey was performed in order to substantiate claims and conclusions. Core characteristics of CI-systems are grouped into “functional requirements” and “non-functional requirements (quality attributes)”. By doing this, it is possible to quantify and categorize various core components and functionalities of a typical CI-system. This study also contains an attachment which provides instructions of how to get started with implementing your own CI-server using the CI-system software ”TeamCity”. The conclusion of this study is that a CI-system is an important tool that enables a more efficient software development process. By making use of CI-systems developers can refine the development process by preventing integration problems, automating some parts of the work process (build, test, feedback, deployment) and quickly finding and solving integration issues.