XP (Extreme Programming) Values

As I’m kind of running a theme of posts about Agile Development, I thought I’d extend that on a little further and do a quick post about the XP Values. As a type of Agile Development, XP Programming encourages short release cycles as well as pair programming and extensive code reviews.

There are five core principals that make up the XP Values, these are described below.

Simplicity

This is fairly self explanatory but XP encourages finding the simplest solution to the problem you’re trying to solve. The ‘nice-to-haves’ and extra functionality can be added at a later date, you’re only interested in finding the simplest, working solution for now. This forces you to think of what is currently needed, not what may be needed in the coming weeks, months or years. It couples nicely with the YAGNI (you aren’t gonna need it) approach, ask yourself this while planning out your MVP and debating whether you need that flashy loading screen or not.

Of course there is there is the argument that with this approach you’re not always building a scalable app, or that whatever is implemented now will need to change based on changing technologies or growing demand. On the flip side, it safeguards against investing in requirements that may change as the development takes place. I’m not suggesting you use Sinatra instead of Rails, I still believe in building something with the ability to scale if the demand grows, but it’s important to keep it simple from the outset.

Communication

I must’ve highlighted this in pretty much all of my previous posts, so I w0n’t harp on again, but communication is key. Everyone has to be on the same wavelength, if there are problems they need to be coherently communicated to other developers, to customers, to clients, to users, to everyone! You need to be able to communicate in all parts of life, it’s what drives everything and builds connections, relationships and forms a big part of creating working software. XP encourages collaboration between all parties, developers, customers and to this end promotes the use of simple designs, so communication is easy and does not become a burden.

Feedback

As with most things Agile, these values feed into each other and reply upon each other. Without communication, you wouldn’t have any meaningful or valuable feedback. This value highlights that every iteration will be taken seriously through delivering working software. The feedback is taken on board and any changes or tweaks are agreed on and implemented. It comes down to being flexible to change, you want to be able to adapt to the project and its needs, not the other way round.

Respect

Similar to communication, it’s important to respect everyone you work with and value what everyone brings to the team. Recognise that everyone contributes something valuable to the team, whether it’s knowledge, creativity or just enthusiasm, everyone brings something different that adds value to the team. This also refers to the relationship between developers and the client and even developers and management. Developers need to respect the client’s requirements and understand the level of expertise they bring into a project. Management also needs to respect developers and allow them to take ownership and authority of the work. Respect is important, it creates an open and honest channel of communication for everyone.

Courage

Lastly, courage. It takes courage to be honest about the progress of work, if it’s not great, and the same goes for calculating estimates for projects. I guess this last one is more about acknowledging the fact it’s tough work sometimes, when deadlines are approaching and clients are chasing, understand you’re not alone and that you’ve always got a team around you. Plan to succeed and don’t make excuses. Sounds pretty dramatic, I know, but work can be hard sometimes and if you fuck up, it takes courage to admit and put things right.

Conclusion

Extreme programming is just a set of values to work to and with a lot of it revolving around communication, it’s easy to see why it encourages pair programming and regular, thorough code reviews. Obviously there are times maybe pairing doesn’t work best, but thats ok, the whole point is to be adaptable, approachable and respectful so you can respond to change in a thoughtful, efficient and productive manner.

I know it’s a short one but, if you enjoyed what you read, hit like, share and follow to keep up to date with my future posts!

Software Developer https://jameshamann.com