Sep 20, 2020

Extreme Programming

We've been doing Test Driven Development and Pair Programming at my workplace for quite some time. They are both part of the methodology developed by Glenn Beck called Extreme Programming (XP). I became curious, are we doing extreme programming? Is there more to it then we do? Let's take a look.

Extreme Programming is sometimes distilled into five values: Communication, Simplicity, Feedback, Courage and Respect.


From Wikipedia we gather:

Extreme programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback.

We do favor collaboration as a knowledge sharing tool in the team, as opposed to extensive documentation explaining everything. We also favor frequent verbal communication through discussing stories at a grooming stage and at a planning stage and whenever necessary. We used to be better with feedback, where we would measure the impact of the features that we had implemented.

One thing, that I believe is part of Domain Driven Design, is called Event Storming, which is a method to make sure that everyone in the project has the same understanding of a project. This has proven great, and has also shown to clarify some misunderstanding.


I really like this one. Simplicity is about: building the simplest possible solution, and not making it more complex until necessary. It is also about refactoring to make sure that logic is not duplicated. This is something I find that we do well.


Wikipedia divides into three forms of feedback:

The first part we do really well. We work according to TDD.

The second one we don't really have. I suppose this would mean that our product owner would produce acceptance tests for us. These kind of tests would be created by us if anything. The requirements are communicated by the Product Owner through stories.

The third one we do. We constantly plan and give feedback to the stories, pointing out missing information or possible ways of simplification.


The courage to throw away code, and to refactor. I think we do this well, with the unit tests in place as well this doesn't become so difficult.


Everyone should be appreciated and respected for the work they do. I believe we do this as good as we can. From my perspective this also means that you don't necessarily refactor other people's code unless there is a more valid reason than just personal taste.


I feel we do most of the things. I notice they favor having a system metaphor and widespread conventions that all people follow with the coding. Our coding is performed over many different repositories, some which we don't own, which unfortunately makes coding conventions a bit difficult. All in all though, I find we are working close to the XP process, and I also feel this makes sense, as I find our work process quite good.