Extreme programming is a language-independent approach to project planning and quality control which aims to lower the cost of changes in development. There is little to no up-front documentation which allows for a more flexible approach to tackle software problems. With that said there is controversy which surrounds the subject matter as these practices don’t come without its drawbacks.
Over the last few days I’ve been getting into some of the Extreme programming concepts in the book eXtreme .NET. The first chapter gives a concise overview of how XP fits into common day business needs. Here are some key concepts that I took from it:
- Whole Team: the customer is always available to discuss and resolve issues.
- Planning Game: where developers sit down with the customer to discuss features of the software which are brainstormed and given priorities.
- Pair Programming: is the practice of having two developers working alongside one another solving a single problem. Both programmers learn from each other and send along the knowledge to the next person who they pair with.
- Test-Driven Development: writing your test cases before beginning to code your solution not only helps you stay focused on the task at hand, it essentially acts as a safety net against breaking existing logic.
- Constant Refactoring: the process of optimizing your code without loosing functionality.
- Spiking: making the effort to experiment and drive your efforts in such a way to learn a new skill which pertains to the project development. It is often done by solo developers who need a break from pairing.
- Continuous Integration: code gets integrated with the solution after each tasks allowing for the team to ship early and often.
- **Stand-Up Meetings: **team members meet every day to discuss progress made as well as spread knowledge to the team.
The Four Five Key Values of XP
Communication
A person’s work environment can persuade his or her empowerment to communicate freely. It is likely there there will be problems if communication is not done properly and frequently. Even worse, a newcomer to the project could be left out on some important piece of information that would cause a delay in development.
Simplicity
Doing the simplest thing possible to move the project forward. By writing simple code, it is more likely to work. Only begin to rewrite a more complex solution when the business need calls for it.
Feedback
Constant feedback from the customer is essential so you can understand exactly what needs to be done and should be done in small iterations. This is especially true when priorities change while deadlines need to be met. Your unit tests provide immediate feedback if your test fails when modifying code.
Courage
By working more intensely for a shorter length of time, you are using your time more efficiently as well as allowing yourself more time to be out enjoying life. Additionally, you must also have the courage to throw away unneeded parts of your code as needs change.
Respect
Having respect for fellow team members by not doing anything which will break the XP practices put in place. Always striving to produce high quality code throughout the project lifecycle.