Motivated by my lack of understanding of the all too common buzz word ‘eXtreme Programing(XP) ‘and Jeff’s Post from last week, I figured I would follow suite and provide a synopsis of Kent Beck’s Episode 37: eXtreme Programming Pt 1. I found that overall XP is a set of best practices for working effectively and feeling valued as a team member. The collective opinion was that XP is the ‘least amount you should do in any given project’, I assume the opinion is derived from the fact that XP promotes productivity, error free code, and the value of the team members.
In expressing what XP is the conceivers found that it was necessary to separate the ideas into categories: values, principles, and practices — with the values being the most abstract, the principles admittedly having the potential to be contradictory, and the practices being concrete and implementable. The values of the XP discipline have remained unchanged from their original authoring but the principles have been elaborated on and changed, as such this summary will largely focus on the first rendition of the principles as the secondary principles seem more open to interpretation as they ranged from equality to economics.
The values of XP where:
- Communication – traditionally thought to be the managers job, XP encourages the whole team to take ownership of this role.
- Feedback – promoted by good testing and involvement of the whole team
- Simplicity – implement the simplest solution that solves the problem
- Courage – largely be courageous in adopting XP, but also know when to scrap a solution that is not making progress in favor of one that will.
The principles of XP:
- quality work – enforced by Pair Programing and required for any non-trivial task to find a resolution.
- incremental changes(babby steps) – re-enforced by unit testing
- embrace change – because the business requirements can be rapidly changing
Practices of XP:
- Sit together – makes it easy to communicate about a problem, although this requires restraint from all team members as this can easily lead to rogue conversations and idle chat/jokes.
- whole team together – often times teams become seperated by function, XP encourages small teams and heterogeneous mixing of managers and all positions on the team to provide accessibility to the members.
- organize workspace – use resources as best as possible, encourages constructing whiteboards if they are lacking and use of post-it notes
- energized work(40 hr week) – work at a sustainable pace, don’t over-exert.
- Pair Programming – as discussed in class and in Pair Programming A and Pair Programming B with the basics being: have 2 programmers taking turns at one keyboard with the non-driver critiquing the code written to reduce the bugs introduced, and the driver should change every couple of hours. This reduces ‘cowboy programming’ (aka: reduces the acquisitions and finger-pointing) as well as increasing the ‘truck factor'(how many people can get hit by a truck before the project goes under)
- Test First(Test Driven Development[TDD])- write a failing test for code and then implement the code to cause the test to pass. Similarly when a bug is found write a test that fails because of the bug then fix the bug. Advocated as a way to design a system not only regression test.
After realizing that I already followed many of the practices of XP I found that I was no longer in the dark and glad that I had a name to put to the collective set of skills that I had been using. As such I look forward to my future XP experiences in this class.