Extreme Programming - Values & Principles
XP sets out to lower the cost of change by introducing basic values, principles and practices. By applying XP, a system development project should be more flexible with respect to changes.
Extreme Programming Values
Extreme Programming (XP) is based on the five values −
Communication
Simplicity
Feedback
Courage
Respect
Communication
Communication plays a major role in the success of a project. Problems with projects often arise due to lack of communication. Many circumstances may lead to the breakdown in communication. Some of the common problems are −
A developer may not tell someone else about a critical change in the design.
A developer may not ask the customer the right questions, and so a critical domain decision is blown.
A manager may not ask a developer the right question, and project progress is misreported.
A developer may ignore something important conveyed by the customer.
Extreme Programming emphasizes continuous and constant communication among the team members, managers and the customer. The Extreme Programming practices, such as unit testing, pair programming, simple designs, common metaphors, collective ownership and customer feedback focus on the value of communication.
XP employs a coach whose job is to notice when the people are not communicating and reintroduce them. Face-to-Face communication is preferred and is achieved with pair programming and a customer representative is always onsite.
Simplicity
Extreme Programming believes in ‘it is better to do a simple thing today and pay a little more tomorrow to change it’ than ‘to do a more complicated thing today that may never be used anyway’.
Do what is needed and asked for, but no more.
''Do the simplest thing that could possibly work'' The DTSTTCPW principle.
Implement a new capability in the simplest possible way. Also known as the KISS principle ‘Keep It Simple, Stupid!’.
A coach may say DTSTTCPW when he sees an Extreme Programming developer doing something needlessly complicated.
Refactor the system to be the simplest possible code with the current feature set. This will maximize the value created for the investment made till date.
Take small simple steps to your goal and mitigate failures as they happen.
Create something that you are proud of and maintain it for a long term for reasonable costs.
Never implement a feature you do not need now i.e. the ‘You Aren’t Going to Need It’ (YAGNI) principle.
Communication and Simplicity support each other.
The more you communicate the clearer you can see exactly what needs to be done, and you gain more confidence about what really need not be done.
The simpler your system is, the less you have to communicate about the fewer developers that you require. This leads to better communication.
Feedback
Every iteration commitment is taken seriously by delivering a working software. The software is delivered early to the customer and a feedback is taken so that necessary changes can be made if needed. Concrete feedback about the current state of the system is priceless. The value of the feedback is a continuously running system that delivers information about itself in a reliable way.
In Extreme Programming, feedback is ensured at all levels at different time scales −
Customers tell the developers what features they are interested in so that the developers can focus only on those features.
Unit tests tell the developers the status of the system.
The system and the code provides feedback on the state of development to the managers, stakeholders and the customers.
Frequent releases enable the customer to perform acceptance tests and provide feedback and developers to work based on that feedback.
When the customers write new features/user stories, the developers estimate the time required to deliver the changes, to set the expectations with the customer and managers.
Thus, in Extreme Programming the feedback −
Courage
Extreme Programming provides courage to the developers in the following way −
To focus on only what is required
To communicate and accept feedback
To tell the truth about progress and estimates
To refactor the code
To adapt to changes whenever they happen
To throw the code away (prototypes)
This is possible as no one is working alone and the coach guides the team continuously.
Respect
Respect is a deep value, one that lies below the surface of the other four values. In Extreme Programming,
Everyone respects each other as a valued team member.
Everyone contributes value such as enthusiasm.
Developers respect the expertise of the customers and vice versa.
Management respects the right of the developers to accept the responsibility and receive authority over their own work.
Combined with communication, simplicity, and concrete feedback, courage becomes extremely valuable.
Communication supports courage because it opens the possibility for more high-risk, high-reward experiments.
Simplicity supports courage because you can afford to be much more courageous with a simple system. You are much less likely to break it unknowingly.
Courage supports simplicity because as soon as you see the possibility of simplifying the system you try it.
Concrete feedback supports courage because you feel much safer trying radical modifications to the code, if you can see the tests turn green at the end. If any of the tests do not turn green, you know that you can throw the code away.
Extreme Programming Principles
The values are important, but they are vague, in the sense that it may not be possible to decide if something is valuable. For example, something that is simple from someone’s point of view may be complex from someone else’s point of view.
Hence, in Extreme Programming, the basic principles are derived from the values so that the development practices can be checked against these principles. Each principle embodies the values and is more concrete, i.e. rapid feedback − you either, have it or you do not.
The fundamental principles of Extreme Programming are −
Rapid feedback
Assume simplicity
Incremental change
Embracing change
Quality work
Rapid Feedback
Rapid feedback is to get the feedback, understand it, and put the learning back into the system as quickly as possible.
The developers design, implement and test the system, and use that feedback in seconds or minutes instead of days, weeks, or months.
The customers review the system to check how best it can contribute, and give feedback in days or weeks instead of months or years.
Assume Simplicity
To assume simplicity is to treat every problem as if it can be solved with simplicity.
Traditionally, you are told to plan for the future, to design for reuse. The result of this approach may turn into ‘what is required today by the customer is not met and what is ultimately delivered may be obsolete and difficult to change.’
‘Assume Simplicity’ means ‘do a good job of solving today's job today and trust your ability to add complexity in the future where you need it.’ In Extreme Programming, you are told to do a good job (tests, refactoring, and communication) focusing on what is important today.
With good unit tests, you can easily refactor your code to do additional tests.
Follow YAGNI (You Ain’t Gonna Need It).
Follow the DRY(Don’t Repeat Yourself) principle. For example,
Do not have multiple copies of identical (or very similar) code.
Do not have redundant copies of information.
No wastage of time and resources on what may not be necessary.
Incremental Change
In any situation, big changes made all at once just do not work. Any problem is solved with a series of the smallest change that makes a difference.
In Extreme Programming, Incremental Change is applied in many ways.
The design changes a little at a time.
The plan changes a little at a time.
The team changes a little at a time.
Even the adoption of Extreme Programming must be taken in little steps.
Embracing Change
The best strategy is the one that preserves the most options while actually solving your most pressing problem.
Quality Work
Everyone likes doing a good job. They try to produce the quality that they are proud of. The team
