Extreme Programming — Is It for You?
Tech Talk | by Prabha Kularathna
Extreme Programming (XP) has been one of the most polarizing and most hyped programming paradigms in the software industry.
In a nutshell, two developers share a single computer; One (called the driver) does the actual coding, keeping the focus on the piece of business functionality that’s being written, while the other (calledthe navigator) observes, keeping the focus on the business problem they are solving and making sure all ends are covered. In other words, the driver has a microscopic and the navigator has a macroscopic grasp over the development.
XP is a full-fledged development methodology with incremental releases, collective ownership and daily stand-ups. Find more info here.
We got the chance to try it out for a few weeks. XP is certainly not for everyone, but based on our experience, we figured that XP would work well for you:
When requirements are not written in stone
XP works well (perfectly in fact) when the functional areas need more exploration and involve a lot of thinking and creativity.
If the exact requirements are not clearly defined beforehand and you have to search for the optimal solution to your client’s business problem, XP is for you. It will take you and the client on a journey of learning together.
When there’s good chemistry within the team
XP provides a natural environment to bridge differences: Think of a seasoned developer working with a junior colleague. Since XP mandates that there should never be a coach-student relationship, the work takes place in the everyone-is-in-the-same-lost-boat way with no one looking up or down.
As such, XP helps the junior learn fast and acquire new skills by closely observing how the experienced developer approaches the problem, designs and writes (quality!) code. Simultaneously, the experienced developer gains insight into the junior’s approach, allowing him/her to understand a younger generation’s perspective and draw from their knowledge.
So for XP to work, you need good chemistry in your team where hierarchy is replaced with open-mindedness and desire to learn.
When it’s OK to get noisy
We figured that pair programming works best when there are open or “unfiltered” communication channels within the pairs. There should be mutual trust and respect among the whole team, however at the same time, all team members should be comfortable with differing opinions.
Some of the more reserved developers might find the process somewhat uncomfortable at first, but, in our experience, this will improve if you can create the environment grounded in trust and consistency.
…
Originally published on www.CreativeSoftware.com/Blog
