1. Introduction
Different developers typically adopt heterogeneous strategies for solving a given problem. Although it is absolutely normal in software development, working on big software projects with large IT teams usually requires programmers to follow some standards. These standards, in turn, aim to enable effective communication between programmers through a source code, thus improving the efficiency of the team.
In this tutorial, we’ll study the four commandments of the simple design of the eXtreme Programming (XP) methodology. Initially, we’ll check a few pieces of information about the extreme programming framework. Next, we’ll analyze these four commandments and investigate what each one exactly means in a programming scenario. Finally, we’ll present some conclusions.
2. The Extreme Programming Methodology
Extreme programming is a software development methodology that employs agile processes. The principal idea behind agile software development is to enable fast delivery of software products by executing low-complexity actions based on an iterative process.
In this context, the XP stands out by having a transparent and accountable process. First, in extreme programming, everyone involved in the project is treated as partners in a collaborative effort, regardless of each one’s position: teamwork is essential.
Second, the XP methodology employs fast methods to accomplish a coding project by following simple rules of five straightforward stages:
- Planning: based on user stories, little planning releases define the project schedule. An XP iteration starts with the planning stage
- Managing: orchestrates the team, the project, and the work itself. Typically, immediate objectives are described in fast daily meetings
- Designing: the pre-coding stage. Uses techniques of refactoring, CRC cards, and spike solutions to get fast and efficient results
- Coding: the hands-on stage, characterized by continuous communication with the customers, continuous integration, efficient use of programming standards, and pair programming
- Testing: XP are mostly based on unit tests, and passing on them is required for making a software release. The unit tests are created in the coding stage before start programming the aimed software
The following image shows a summarized flowchart of the XP’s workflow:
In short, we can summarize XP in five pillars: communication, simplicity, feedback, respect, and courage. In our particular context, we will deeply explore the simplicity pillar, understanding how it reflects each XP stage and the development process as a whole.
3. The Simple Coding Design
Defining what is simple or not is a challenging task. The question is: what really turns software or an algorithm simple? Maybe, a potential answer regards using the most straightforward strategy for solving a problem. But, in such a case, simplicity may impact the software’s performance.
Another possibility consists of understanding simplicity as adopting the strategy that executes the less possible number of operations to solve a problem. However, this strategy may represent a very complex algorithm from a coding perspective.
Thus, considering the previously presented questions, the XP methodology provides a framework for determining the desired characteristics of a simple code in a software development context. In summary, this framework consists of four commandments:
- Pass all the tests
- Be clear, expressive, and consistent
- Duplicate no behavior or configuration
- Have minimal methods, classes, and modules
To achieve simplicity, XP focuses on defining routines and good practices that lead to a simple and sustainable coding process and, finally, to a simple to maintain and update/upgrade software.
There is no clear and definitive priority order among the XP simplicity commandments. However, some authors suggest a preference order based on the relevance of the commandment in other XP pillars and stages. The following figure shows such ordering:
To better comprehend XP’s simplicity, we will specifically explore its four commandments in subsections next.
3.1. Pass All the Tests
The first commandment of XP simplicity (sometimes referred to as “run all the tests” too) is typically considered the most relevant by many software developers.
The unit tests are a first-class activity in the XP methodology. It means that they must not be disregarded, and other stages or iterations of the software development process depend on the unit test results.
The relevance of tests comes from the operational guarantees it brings to the software under development. Tests represent the expected behavior of a given piece of code or system fragment. In this way, achieving simplicity means that the final software will execute the expected operations in an expected manner.
Furthermore, passing all the tests indicates to the programmers when the software is complete. It avoids not implementing a required functionality as well as implementing functionalities not desired, making the software unnecessarily complex.
3.2. Be Clear, Expressive, and Consistent
Making the development process and the released software clear, expressive, and consistent is the right way to fulfill the simplicity pillar of XP programming. Sometimes these requirements of simplicity are called revealing the intention or cohesion maximization.
From a practical perspective, this commandment of simplicity means that all the team working on a project must efficiently understand the code and the software on development: communication is a core necessity to make XP work.
From a technical perspective, however, more than writing code, the programmers and the other entities involved in the project must express their intentions by doing it. A manner to that is adopting programming standards and documenting the code: it goes from using meaningful names for variables and constants to writing strategic comments.
The main idea of this commandment is to remember that both people and machines will read the code of the software. Thus, it is not enough for a source code to be syntactically and logically correct for the execution. XP also expects it to be clear and understandable for any programmer.
3.3. Duplicate No Behavior or Configuration
Duplicated functionalities and resources make software and its code complex and hard to maintain. So, XP strongly suggests avoiding doing that. We can find this commandment with other names, such as coupling minimization or no duplication.
The watchwords here are: every behavior must appear once and only once in a source code.
We want a simple code that we can maintain with less effort possible. Duplicates of operations, data, and configurations spread in a software code make updating and upgrading processes a nightmare.
Thus, the first movement to accomplish this commandment is thinking atomic when programming the software. If the software requires the same functionality in multiple places, we should make it accessible in these places but not duplicate it.
The second movement, in turn, is refactoring. Even paying attention, duplications may occur sometimes. The great news is that we can solve these duplications by refactoring the code: searching and solving duplications are considered one of the most relevant tasks of code refactoring in XP.
3.4. Have Minimal Methods, Classes, and Modules
The last commandment of simplicity relies on the evaluation of the last three ones. We can summarize it as: if something does not fit in the other three commandments, remove or do not implement it. This commandment is sometimes called minimal elements or no superfluous parts.
The first practice to reach software with minimal methods, classes, and modules is avoiding implementing functionalities for future usage. So, if there is a functionality that is not immediately required by the software, do not implement it. It will save time and make the code more understandable and clean.
It is relevant to highlight that this does not necessarily mean merging functionalities all the time. Classes, for example, must be complete and follow the responsibility rule: a class has a single responsibility – it does it all, does it well, and does it only. In this manner, if a class is necessary, we should implement it, but it must contain the exact functionalities that the software needs, no more.
4. Conclusion
In this article, we studied the four commandments of simple design in the context of XP methodology. First, we saw some basic concepts about the XP methodology and its objectives. So, we could explore the four XP commandments of coding simplicity:
- pass all the tests
- be clear, expressive, and consistent
- duplicate no behavior or configuration
- minimal methods, classes, and modules
The XP’s commandments of simplicity are realistic directions. We can adapt and use them with multiple programming paradigms or languages successfully. By adopting this simplicity-tailored framework of four commandments, we can make released software long-living and easy to maintain.