eXtreme Programming and OSS development � a comparative studyBy Sankarshan Mukhopadhyay


Introduction

Traditionally �engineering� is more used for tangible things. Engineering has over ages developed to deal with houses, bridges, cars, factories etc. In the realm of software, �software engineering� is a different developmental model altogether. Due to its flexible nature, software can be modified very quickly. Moreover, it is built on and through other software including OS and APIs, programming and development environment etc. Yet software can, and is often, highly complex with large amount of lines of code, cross dependencies and links. A solid, robust and standard development model is required to ensure that software development is as fault-free as possible.

Eric Raymond, in his now famous �The Cathedral and The Bazaar� outlines the prevalent models of software development. These can be between 2 extremes: Code and Fix � where developers tend to produce copious amounts of code and then attempt to debug it into some semblance of ordered logic, and, Formal Methodology � where development is managed and focused by means of audited processes and standards and the pitfalls and the bottlenecks are identified beforehand so as to take precautions.

Focus of this article

Currently, software development is a cross cultural and collaborative developmental effort spanning geographical domains. As such, there is a distinct need to implement a focused �agile� development paradigm. extreme Programming and Open Source Software development models are two of the prevalent paradigms that challenge the earlier fixed parameter model by incorporating software best practices. Although the OSS model is a favorite of the OSS development community, the article aims to find the common ground and conflicts between these two apparently �divergent� practices. It is aimed at practitioners of at least one of these development paradigms and students of software design models.

This was originally planned as a talk at one of the iLUG-Kolkata monthly meetings; the slides are available from the home page of the users group as well as by request to the author.

extreme Methodology

This methodology, defined by Kent Beck in the early �90s, represents the most popular of a new breed of software processes collectively known as �Agile Methodologies�. The name is a bit misleading as the only radical and extreme element of the model is related to software best practices. Such practices include testing, customer feedback, iterative and incremental development and code reviews. The model embodies a collection of the 12 best practices along with the notion of �embracing change�. As an agile methodology, it seeks to enable a project, the people of that project and the resultant output of the development effort to not only react but also take advantage of changes of requirements, personnel and design and architecture. The key factor is the flattening of the cost of change curve. This curve is related to the long-held axiom in software development that changes become exponentially more expensive to make as a project progresses (more so if such changes occur across phase transitions). XP, through a disciplined use of its complementary practices, constant feedback and iterations consisting of testing, analysis, design and coding flattens this curve.

Each of the set of XP practices focuses the energy of the development team on 4 fundamental �enabling� values: Courage, Simplicity, Feedback and Communication. Each of these values pervades the decision-making and the daily work of practicing XP teams. XP requires discipline, it is a team discipline that leverages the knowledge of each member of the team by moving and focusing knowledge throughout the team, taking advantage of the strengths, and offsetting the weakness of the team as a whole.



The prevalent best practices in XP are listed as:

1. The planning game: the XP practice of planning ensures that domain specialty and expertise is kept as a functional component. Customers understand their businesses better and developers perform best as technical consultants. Customer and developers planning together for the project and scheduling review dates creates a joint application development effort that help them understand their mutual capabilities and limitations better. The essence is to stick to a simple plan and continuously refine it jointly to reflect changes in project situation and needs.
2. Small releases: the idea is to quickly produce a working prototype so as to enable the end-users to visualize and quantify the business value of the features. Technical snags and functional defects are dealt early on in the development cycle. Small releases help both the customer and the developer to understand the context better and fully exploit the technology to design features that could deliver a high business value.
3. Metaphor: the issue of client-developer communication is taken care of by usage of metaphors in the XP development process. Metaphors are used as a tool to visualize, communicate, understand and implement a feature in totality.
4. Simple design: keeping the design simple at each stage of release ensures that it is possible to implement change factors with least time overruns. Simple design also facilitates the early start of the development cycle and rapid refining of design parameters at each release stage.
5. Testing: XP methodology insistence of accepting code only after it has passed all test ensures that code integration is as smooth as possible.
6. Refactoring: when features are being added in successive releases, fine tuning the new release and optimizing it to ensure homogeneity becomes imperative. Programmers undertake refactoring any time there is a redundancy. Refactoring thus guarantees that at any point of time, the application retains its optimum capability and at no point of time does the program act like a patch.
7. Pair Programming: in general the most hyped aspect of XP has been the concept of �pair programming�. It was originally planned as a means to increase software quality and productivity. It also balances skills in individual programmers and forms an insurance against attrition while at the same time fostering and nurturing team spirit. Pair programming is designed to create �mentors� and informal coaching to bridge skill gaps. With dynamic pairing, every team member obtains a top-view of the system and is thus involved in every stage of the design and development work.
8. Collective ownership: in XP everyone takes responsibility for the whole system. Although not everyone will know the parts of the system equally well, everyone knows something about every part. Thus anyone who sees an opportunity to add value to any portion of the code, is required to do so. Anyone can change any code anywhere in the system. Thus the team wins or loses. This ensures that the evolution of design is not slowed down and the usual problems of projects suffering from member attrition and dislocation are strategically mitigated.
9. Continuous integration: XP is designed to perform as a �bottom-up� validation model to software development as opposed to the traditional �top-down� approach. By means of continuous integration XP ensures that work completed by different and diverse teams are cohesive in nature as a natural consequence of the incremental approach.
10. On-site Customer: an astonishing number of lines of code is wasted in projects due to mistaken assumptions about customer needs and constraints. Requirements Engineering issues occupy prime position in most problems in software projects. XP bridges this gap by having a customer on-site as part of the project team. The customer is present as a representative of the end-user and is thus available to clarify doubts, answer queries and set priorities. Thus while the problem of lack of knowledge about the customer�s business domain is overcome, customers also have �ownership� in both the development and implementation phases.
11. Coding standards: Kent Beck states �programmers should write all code in accordance with rules emphasizing communication through the code for common understanding by all. With pairs swapping, refactoring all day, you simply cannot afford different sets of coding practices. With a little practice, it should become impossible to say who on the team wrote that code. The standard should call for the least amount of work, consistent with the �once and only once rule� (no duplicate code). The standard should emphasize on communication and is adopted voluntarily by the team. �
12. 40-hour week: the ability to impart and implement �flexible working hours and practices�. This ensures that the workload is uniform by design, flattening out the peaks and troughs. The planning game thus ensures that the work is fed in a continuous stream.

Open Source Software development model

The Open Source model of Software development has its origins in the �hacker� movement of the 1960s. It enjoys considerable patronage as the chosen development model for a number of famous projects including the GNU/Linux kernel, Apache and Mozilla etc. The Open Source model is based on the �bazaar� model of globally distributed software development propounded by Eric Raymond. One of the major USPs of the model is that the code produced/developed under this paradigm is �shared�. The source code is allowed to be studied, modified and redistributed. The licensing policy ensures that this is implemented. Thus when compared to standard proprietary software development model, it possesses a considerable amount of unique character and values based on community oriented outlook. Being based on a global distribution model, it has no such established �standards� as to developmental methodologies and process flow.

Areas of Conflict

The very nature of the development model of XP and OSS leads to a few areas of conflict. XP is based on team empowerment and collective ownership of the produced code. OSS on the other hand is defined by the shared source community based approach of its model. XP is generally used for localized projects due to the following factors: Planning Game, On-site customer, Pair Programming. OSS being based on the distributed development model and thus cannot possibly have the advantage offered by pair programming and joint application efforts. Nowadays with the growth in virtual teams, such a lacunae is being overcome. And thus a convergence is occurring as to the 2 methodologies.

Areas of overlap

Although in a phase of casual observation the development models are divergent and conflicting, in reality, they are not so different. As will be evident from the above discussion, considerable areas of overlap in form and content exist. Since both the models are aimed at reducing the cost of change and encouraging reuse of components, the following aspects of the models are similar: Simple Design, Metaphor, Refactoring, Iterative small releases, Coding Standards, Continuous Integration, unit Testing, Code Reuse and 40-hour weeks. All these aspects when taken in complete form actually help in removing the normally observed factors that impede development of robust and stable software.

Conclusions and reflections

A Google search reveals strong communities of practitioners of the development models. And this is due to the common values shared by these two: Communication, Simplicity and Continuous Feedback. They represent the way in which �programmers like to work�. With Open Source software development model being adopted in a distributed/globalized project development environment, project deliverables assume critical importance. Incorporation and implementation of XP practices to reduce the project costs and meet project delivery schedules would benefit end-users by ensuring the quality of software. XP practices are semantically similar to existing Open Source Software practices and increase the value proposition of the software. Project deliverables are of consistent and verifiable quality. Testing modules written specifically for units ensure adherence to established protocols and models.

In the case where the development models work in synergy, the end-user is benefited by being ensured of robust and high quality of software.




References

� Kent Beck: �eXtreme Programming explained - Embrace change�
[ISBN: 0201616416]
� K Beck, M Fowler: �Planning Extreme Programming�
[ISBN: 0201710919]
� E S. Raymond, B Young: �The Cathedral and the Bazaar�
[ISBN: 0596001088]
� �Open Sources: Voices from the Open Source Revolution�
[ISBN: 1565925823]

URLs

� Indian Linux Users Group-Kolkata: www.ilug-cal.org
� Google: www.google.com
� Extreme Programming: www.xprogramming.org

Sankarshan Mukhopadhyay is a Free Software enthusiast and a member of the Indian Linux Users Group-Kolkata Chapter http://www.ilug-cal.org/. His blog �Random Thoughts� is at http://sankarshan.blogspot.com/ He can be reached at sankarshanm@softhome.net






- posted by sankarshan @ 4/04/2003 10:02:00 PM