One of the first agile software develpment methods was Extreme Programming, or short XP, that received a lot of attention in the beginning of the millennium.
Quality and Scope
In the book Extreme Programming Explained, Kent Beck (2000) presents a model for software development to explain some of the decisions made in XP. In this model, a software product is controlled by four parameters:
Cost is basically the price of the product which again correlates strongly to the number of people assigned to work on the project.
Time is the amount of time to the delivery deadline.
Scope is the size of the project in terms of required functionality.
Quality is aspects like usability, fitness for purpose, and reliability.
These four parameters have a complex relationship, and changing one in a project affects the others. The relationship is, however, not simple. For instance, you may deliver faster (decrease time) by putting additional programmers on a project (increase cost) but doubling the number of programmers will certainly not cut the delivery time in half.
The point made is that often organizations decide the first three parameters (cost, time, scope) and leave the forth parameter (quality) as the only free parameter for developers to control. Typically, the onset of a project is: We have three months (fix time) to complete the requirements in this specification (fix scope) and this group of eight developers are assigned (fix cost). As estimates are often optimistic, the developers have no other option than sacrifice quality to meet the other criteria: delivery on time, all features implemented, team size constant. Even still, our software development profession is full of examples of projects, that did not deliver in time, did not deliver all features, and went over budget.
XP focuses on making scope the parameter for teams to control, not quality. That is, the three parameters cost, time, and quality are fixed, but the scope is left open to vary by the team. For example, consider that three features are wanted in the next small release, but after work has started it is realized that there is not enough time to implement them all in high quality. In XP, the customers are then involved to select the one or two most important features to make it into the release. Two working features are valued higher than three defective or incomplete ones.
Needless to say, this swapping of the roles of scope and quality in XP is underlying many of its practices:
- to control and measure quality, automated testing is introduced, and made into a paradigm for programming called test-driven development. To ensure code quality, refactoring is integrated in the development process.
- to control scope, an on-site customer is required so the interaction and decisions can be made quickly and without distortion of information. Small releases are produced frequently to ensure time is always invested in those features and aspects that serves the user’s need best.
Values and Practices
XP rests upon four central values
A primary cure for mistakes is to make people communicate with each other. XP value interaction between people: between developers, with customers, management, etc.
“What is the simplest thing that could possibly work?” In XP you focus on the features to put into the next small release, not on what may be needed in six months.
You need feedback to know you are on the right path towards the goal, and you need it in a timely manner. If the feature you are developing today will not suit the need of the customer you need to know it today, not in six months, to stay productive. XP focus on feedback in the minutes and hours time scale from automated tests and from the on-site customer, and on the week and month scale from small releases.
It takes courage to throw away code or make major changes to a design. However, keep developing based on a bad design or keep fixing defects in low quality code is a waste of resources in the long run.
Based on these values, a lot of practices have evolved. Below, I will describe a few that are central to the practices of programming. It should be noted that XP contains many more practices but these are focused on other aspects of development such as planning, management, and people issues.
A central technique in XP is pair programming. Code is never produced by an individual but by a pair of persons sitting together at a single computer. Each person has a specific role. The person having the keyboard focuses on the best possible implementation at the detailed level. The other person is thinking more strategically and evaluates the design, reviews the produced code, looks for opportunities for simplifications, defines new tests, and keeps track of progress. The pairs are dynamic in that people pair with different people over the day and take turns having the two different roles. To make this work, collective code ownership is important: any programmer may change any code if it adds value for the team. Note that this is different from no ownership where people may change any code to fit their own purpose irrespective if this is a benefit or not for the team. Collective ownership also force programmers to adhere to the same coding standards i.e. the same style of indentation, same rules for naming classes and variables, etc. Pair programming is both a quality and communication technique. It focuses on quality because no code is ever written without being read and reviewed by at least two people; and there are two people who understand the code. And it focuses on communication: pairs teach and learn about the project’s domain and about programming tricks. As pairs are dynamic, learning spreads out in the whole team.
Automated testing is vital in XP. Automated testing is testing carried out by the computers, not by humans. Computers do not make mistakes nor get tired of executing the same suite of 500 tests every ten minutes, and they execute them fast. By executing automatic tests on the software system often, the system itself gives feedback about its health and quality, and devel- opers and customers can measure progress. These tests must all pass at all times. To get feedback on the “fitness of purpose” you make small releases frequently: once every month, every two weeks, or even daily. A small release is a working, but functionally incomplete, system. At the beginning of a project it may serve primarily as a vehicle to discuss fitness of purpose with the end users and customers; however as quickly as possible it will be deployed into production and used with ever grow- ing functionality. Continuous integration means that the development effort of each pair programming team are continuously added to the project to ensure that the developed code is not in conflict with that of the other pair teams.
Customers’ and users’ requirements are captured as stories which are short stories about user-visible functionality. These stories are written on index cards and given short headlines, like “Allow stop of video recording after a specified time interval”, “Align numbers properly in columns”, “Add currency converter tool to the spread- sheet”, “Compute account balance by adding all deposits and subtracting all deduc- tions,” etc. Finally, they are put on a wall or some other fully visible place. Also each story is estimated for cost in terms of hours to implement. This allows developers and customers to choose those stories that provide the best value for the least cost. Stories should be formulated so they are achievable within a 4–16 hour effort of a pair. Once a pair has selected a story, it is further broken down.
XP is a highly iterative development process. Work is organized in small iterations, each with a well defined focus. At the smallest level, an iteration may last a few minutes, to implement a simple method in a class. At the next level, it may last from a few hours to a day, to implement a feature or a prerequisite for a feature, and ends in integrating the feature into the product. And at the next level again, the small release defines an iteration, lasting from weeks to a month, to implement a coherent set of features for users to use. It follows that it is also an incremental development process: systems are grown piecemeal rather than designed in all detail at the start. The strong focus in XP on people interactions means it is suited for small and medium sized teams. Large projects with many people involved need more rigor to ensure proper information is available for the right people at the right time. This said, any large project uses a “divide and conquer” strategy and thus there are many small teams working on subsystems or parts of a system and these teams can use XP or another agile method within the team.
Published on Mon 13 February 2017 by Shane Dowling in Programming with tag(s): programming