eXtreme Programming ‘XP’

Swift methodologies for developing IT systems
Ilham Chmiti
Sergio Merino Martínez
Lisardo Fernández Cordeiro
ETSE – 2º GII – IS
University of Valencia
Versión en español


Hyperactivity has always conflicted with thorough and thoughtful work; where timeframes are in line with methodical guidelines, and whose outstanding success and gleaming victory is guaranteed. Or at least that is what we have always been told.
Even in the most vehement discussions, there has been speculation about the apparent lack of ground for big investments in studies leading to the search for models and methods that set out procedures, guidelines and philosophies to optimise success, as it cannot be just anything.
But if Platon peacefully observed the world from a cave, with absolute belief he would establish a rigorous guideline about what is essentially appropriate to reason and truth, Socrates was the one who, with self-confidence, took charge of the tasks while creating reliable and simple concepts to irritate his fellows.
Part of the current creative trend is based on this. Without giving or challenging reasons, it is sensible to adapt methodologies that are entrenched to designs and conceptual views prior to inclusion in the mud of the code generation, so that the hyperactive and excited code typist can start their work rigorously but without delay.
Adapting projects to models is not always the correct order and this is important. Methodologies need to be changed according to the dimensions, objectives and functionality of the project.
Nowadays, it is believed that extreme specialisation illiteracy, with completely tight departments, only creates problems for the future, including expensive maintenance, complex updating and, lastly, reduced product life.
Swiftness, simplicity and cooperation are reasonable and powerful alternatives to ensure that a system’s life circle is economically feasible for its stability.
swift introduction
Today’s fast pace world requires anything that takes a few basic principles. This select, impatient few only can accept a wonderful look, cheap – if not scarce – maintenance and quick developments that introduce solid applications with chameleonic capabilities.
These are not just features but, rather, requirements in order not to miss the single track train ahead of us. This way, the micro-world we live in, enriched by the growing dependency of management, control, automation and leisure applications, does not settle with anything that comes from the autistic of the code, as this does not contemplate and analyse the real needs of future users.
On the other hand, the big challenges formalised with much hierarchical orthodoxy at tight levels, show complexity that does not adapt to the requirements of flexibility and continuous change, no matter how rigorous the piles of generated documentation may seem, together with astonishingly high representation bills.
It is, therefore, through the fusion of these conflicting worlds we will find the appropriate way to get out with enough dignity in stormy moments and vital paradigm changes.
The design is essential for the challenge of developing software applications. It is about establishing the initial and essential paths to base a coding job without it resulting useless. It is about keeping it basic and adding continuous improvements, enriching its functionalities with criteria and care, bringing the design closer to its implementation to go hand-in-hand, obtaining the benefits of reliability, flexibility, robustness and development speed the clients want.
In the following sections we will briefly explain what is eXtreme Programming, one of the most agile software design methodologies, bringing the best results to the experts in the development of the increasingly necessary technology.
basic principles
The most basic principle that any agile methodology must comply with is software creation in the most structured way possible and within the initial budget. In order to comply with this in a simple and secure manner, a number of rules are set for code creation. [1]
As can be seen in diagrams 1, 2, 3 and 4, these rules are as follows (they will be explained in more detail later on):
– Planning 
– Metaphorical system (Metaphor)
– Programming in pairs 
– 40 hours per week 
– Small versions 
– Simple designs
– Continuous testing
– Refactoring
– Collective ownership of the code
– Continuous integration
– The client’s role
– Coding standards
Let us look at these in more detail:
Planning
To do a good job we need to plan properly.
Therefore, we should only get started once we have the diagrams we need in order to implement them, paying attention to them without adding or changing information. This will help us give the client exactly what they want, thus minimising the risk of useless work.
Metaphorical system (Metaphor)
This is about creating a system for the naming of variables, functions, etc. This will speed up the process of thinking of names and/or figuring out the meaning of a name given by another person. Ultimately, this leads to a highly clean code.
Programming in pairs
Code implementation will be carried out in pairs, so that there are fewer errors, as another programmer with the same knowledge of the system will be correcting the code as it is being written. This is also very good for another important reason; programmers can relax as they are not under the pressure of the common mistakes at semantic or syntactic level.
40 hours per week
Based on the previous point, that is, the programmer’s relaxation. That is exactly what we want here; doing too much work in one go does not guarantee the programmer’s efficiency, as many mistakes can be made due to fatigue caused by constant work. These 4o hours can be divided in different ways, and each person may have their own preference.
Small versions
Ideally the client should explain clearly and concisely what they need, but as we already know this does not usually happen as the client does not have the necessary knowledge to know how to explain it so that everything is clear for the subsequent programming of their project. For this reason, small versions are created. What are they? Easy, they are simply versions of the main programme, which we will be showing the client for their approval confirmation and to make sure that it is what they want. They may not have the knowledge to explain it in an understandable way at implementation level, but they do have broad knowledge in their work area, which this software is based on.
Simple designs
The best way to create a clear code is to create simple but effective code. This means that the algorithm used should not be redundant and should make the most of the resources by being efficient. In other words, the programme should do what it is expected to do without errors, especially at final data level.
Continuous testing
This is simply about running constant tests as we implement the code. An effective way to do this is using the abovementioned small versions, testing these as necessary before including them in the main or final programme.
Refactoring
As usual, our objective is to create the simplest code possible, avoiding redundant or repeated code as this could severely affect our code.
Collective ownership of the code
This is a more efficient way of creating a code as the code created by the team also belongs to each member of that group, who can make any necessary changes and improvements without having to asking for any type of authorisation.
Continuous integration
Following our objective of clear code, we know that we should introduce changes that favour such clarity and we should also integrate it as soon as possible and not wait for changes to accumulate.
The client’s role
One of the main characteristics of XP is communication, therefore communicating with the client and making them part of the project allows, or at least facilitates, their understanding of the functionality, which in some cases can be the hardest, most expensive and slowest step in the project’s development.
Coding standards
None of the previous rules will mean anything if we do not follow the well-known standards that significantly facilitate code understanding; not to mention the increased efficiency when deciding beforehand the best standard to satisfy the requirements of the client.
maintenance… that is the question
In addition to living a comfortable life… doing nothing, one of humanity’s big objectives is to elaborate software that is simple and cheap to maintain. If there are no mistakes, we save on treatment maintenance and we keep continuous improvement as the only maintenance cost.
The truth is this sounds great.
However, in order for this to happen we must establish strict protocols for software treatment to ensure that there are no code errors.
As shown in the previous section, eXtreme Programming focuses largely on orientating the development towards the code simplicity and to continuous testing of each block or section in which the project has been divided.
It is important that the reader is aware of the role of design in this process, as the occasional demand of the code generated in each iteration of the development must comply with the guidelines marked by the status of the design at each stage of the development, facilitating its adaptability.
Maintenance of the code in current times, where personnel costs must be adjusted as much as possible in a sector that traditionally suffers from software neglect by analysts and designers, cannot entail an effort that is many times that of the development itself [2].
Client treating of countless problems –bugs- in applications developed with traditional methods only adds mistrust about the capacity of the designers or the development team… or to both. Mistrust does not help in a world that sees these behaviours in a natural way.
That is precisely why the client needs to change their way of thinking about software demands. As maintenance cannot be avoided, we should devote its cost to improving features, enriching functionalities based on the users’ requirements, adapting the design to ever-changing trends and everything that means the innovation of the basic platform developed. This is the only way to preserve maintenance costs in delimited thresholds that are proportional to the design and main development stages.
refactoring, software ecology
If the curious reader sees a concept as ambiguous as incremental design [8], they will quickly change their opinion so that they do not miss how to apply software development.
In the previous section we explained the benefits of treatment development. However, this is not achieved with just systematic application of the code on test batteries; the cost of changes following an error during testing or due to design modifications by the client is proportional to the development status of the system.
That is precisely why the code should have the lightest and simplest structure possible throughout its evolutionary process.  Therefore, we will establish an important concept within eXtreme Programming: refactoring, or continuous revision of the code.
Keeping to the essential and focusing on the important things seems far from the cruel reality, where the unimportant and incidental aspects push hard, perhaps to conceal what is important or to avoid focusing on it. In any case, maintaining code that does only and exclusively what is asked in each moment, without meaningless frills or super-cool extras that end up tarnishing the code, provides the ideal setting for global growth, interaction and flexibility, highly facilitating any later adjustment, modification or fix.
At this point, the bright reader will see that we are reducing system maintenance costs with the simple idea of generating simple code. However, achieving this involves a design and implementation discipline that is slightly risky for non experts.
The term refactoring entails being ready to generate simple code based on simple designs, subject to continuous testing and shared with as many external interventions as necessary to get to the precise minimum base that makes up each block.
But it goes even further. Refactoring does not end when the independent unit has successfully run all tests. It goes through the same process again as it interacts with the rest of the design units indefinitely while the system is not delivered, thus preparing a high reversibility set in case of design changes or inaccurate functionalities.
As Jim Highsmith points out in the eXtreme Programming white paper [2], refactoring does not change the observable behaviour of the software, but it improves the internal structure. In fact, when it comes to adding new functionalities, the first step is often refactoring, in order to prepare the simplest possible environment so that new functionalities can be easily integrated with fewer errors.
communicating simplifies feedback and courage
eXtreme Programming is based on five key values, i.e. communication, simplicity, feedback, courage and respect, which was added in the second edition of eXtreme Programming Explained by K. Beck.
As everyone knows, communication has always been a key means for both humans and animals. It is a way to avoid problems, although there are always construal problems, and for this reason communication among programmers has to be as simple as possible. This means that it is not enough to have an effective code, but it also has to be simple, straightforward and easy to understand.
Programmer/client communication represents an important step to carry out the objective, given that the client is part of the development team and helps the programmer when it comes to resolving questions and specifying requirements.
Simplicity basically consists of achieving the objective through the shortest and simplest way, this way it is possible to easily develop or change the application every time it is necessary.
In the life of a project, changes are inevitable and the project may have to be modified at any time; to do it correctly, first we should think about feedback. Feedback allows us to implement the correct solution keeping in mind a series of steps that help simplicity and functionality, therefore the simpler the system, the easier it is to get good feedback.
Fear is the most dangerous human feeling because it affects the consequences of our actions, our way of thinking and our logic, and given that there are many changes that need more or less courage, the only way to solve any type of problem is, necessarily, to be courageous. Communication, simplicity and feedback also benefit from courage when it comes to obtaining specific information to act.
Respect is also very important; if people in the same team do not respect each other, they will be lost and will not know how to specify the objectives and/or how to achieve them. All the previous values are based on respect.
conclusion
Words of wise men have always served as an inspiration and a guide in the dawn of any activity. Therefore, there is nothing better to conclude than the words of philosopher and economist Karl Marx.
“The philosophers have only interpreted the world in various ways; the point, however, is to change it.”
This particular, swift methodology is working on it, putting into practice without delay any idea that is considered a good one and avoiding the paralysis brought by the excessive orthodoxy of the traditional Byzantine methods.
bibliography and/or web references
1..eXtreme Programming. José Carlos Cortizo Pérez, Diego Expósito Gil and Miguel Ruiz Leyva
2..Agile Project Management – Advisory Service – White Paper. Jim Highsmith
3..http://www.extremeprogramming.org
4..http://www.extremeprogramming.org/rules.html
5..http://www.agile-process.org/proverbs.html
6..http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node61.html
7..http://c2.com/cgi/wiki?ExtremeProgramming
8..http://www.programacionextrema.org/articulos/designdead.es.html
9..http://xprogramming.com/book/whatisxp
10..http://en.wikipedia.org/wiki/Extreme_programming
11..http://es.wikipedia.org/wiki/Programación_extrema

Un comentario sobre “eXtreme Programming ‘XP’

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *