•October 01, 2014
Extreme Programming was introduced to the world in the late 90s as a way to embrace the change that is inherent in Software Development.
Though not a perfect approach to software development, it is a vast improvement over many of its successors.
RoleModel Software was one of the pioneers in the application of the principles of Extreme Programming (see Extreme Programming Applied), and we have continued to evolve the way we apply these principles and others every day.
The heart of Extreme Programming is to diligently apply, examine, and refine, best practices of software development. The heart of the Craftsmanship Academy is to train up craftsmen who diligently apply, examine, and refine best practices of software development.
As one of his assignments during his Residency, Braxton Plaxco read Extreme Programming Explained. Below he has shared his insights into the application of the principles as he is learning to put the theories into practice.
Extreme programming (XP) is best described by Kent Beck when he says, “When I first articulated XP, I had the mental image of knobs on a control board. Each knob was a practice that from experience I knew worked well. I would turn all the knobs up to 10 and see what happened. I was a little surprised to find that the whole package of practices was stable, predictable, and flexible.” A few of the practices he described are: The Planning Game, Short Releases, Metaphor, Simple Design, Testing, Refactoring, Collective Ownership, Continuous Integration, 40-Hour Week, On-Site Customer, and Coding Standards. Working in a studio that strives to implement the principles behind these XP practices in their daily operations has given me the opportunity to experience and grow from each of these in one form or another.
The Planning Game consists of defining a scope for the project in light of business priorities resulting in estimates for each task. While working at RoleModel I have had the opportunity to work directly with customers in determining which new features should be implemented in the next release. I've had to learn how to give estimates for a variety of tasks, while also assessing the value that certain features will add to the project. Often a feature is started with a general concept in mind. Refinement of the feature takes place as it is being developed. Refinement comes in the form of questions and input from the client. The project continuously evolves as direction is defined to meet the needs of the clients.
The concept of Short Releases is to put as simple of a system into production as possible and to release new versions on a short cycle. Short releases help to continually add value to the project as well as reduce code conflicts. In most of the projects I have worked on with RoleModel as soon as I am finished with a task, the tests are run, the code is reviewed, and then the feature is deployed for customer review on a staging server. Once the customer is content with the feature and all of the final tweaks have been made, it is deployed to production.
The Metaphor for the project is a narrative explaining what the system does. The metaphor guides the development process and helps the developers to keep the project's overall goal in mind. I've worked on projects that have had a strong, clear metaphor. I have also worked on projects where the metaphor was not clearly defined. Projects with strong metaphors were fun and enjoyable to work on. I knew the direction of the project, and this increased my motivation for completing tasks. It helped me to take ownership of the project and to want to do everything in my power to see it succeed. On the other hand it has not been as enjoyable to work on projects with out a clear metaphor. In those projects I often find myself wondering what the purpose is of the feature I'm working on. This usually leads to frustration. It is hard to take ownership of a project when you don't know exactly what it is that your project is trying to accomplish.
This is one of my favorite parts about XP programming. It is designing a system as simply as possible, while removing unneeded complexity from its components. When writing code I try to break the task down into its basic elements, figure out how each element might be approached, and then see what the language has to offer to solve the problem. I am not a fan of overly 'creative' and 'clever' solutions because they can be difficult to maintain. I like code that is easy to read at a glance, and I love when I have the opportunity to clean up existing code, making it more maintainable.
This was one of my least favorite parts about XP programming. Programmers are supposed to write unit tests for each part of their code and all tests should pass for the project to progress. Also, customers can write high-level feature tests. Note that I say that it was one of my least favorite parts. I've actually grown to enjoy TDD (Test Driven Development) quite a bit. It allows me to code with more speed, confidence, and precision. The speed and confidence are because I am less fearful that I'm going to break a part of the app. With good coverage, I know things are working properly. If I do make a change with unexpected side effects, a test will fail and I will know that I affected more than I meant to. I haven't actually had the chance to have a customer write the feature tests yet, but I usually take the task card and turn it into a feature test, so that I know that when my feature test is passing then the task is complete.
Refactoring is going over code again, removing redundancy, simplifying it, making it more flexible, etc… without changing its behavior. I love this part of coding as well. It's a fun challenge and helps me grow as a programmer. There have been times in projects where I got it working but it was only so that I could wrap my brain around the concept. The code was never intended to go into production (at least not in its current state). It still needs to be refactored. We were brainwashed… I mean indoctrinated… I mean taught the phrase "RED, GREEN, REFACTOR!" while in the Craftsmanship Academy. This phrase means you should always have a failing test, then make it pass, and finally refactor the code ensuring higher quality.
This is the concept that no one person owns the code in a project and therefore anyone is free to make changes anywhere in the code. With good test coverage, it is nice to know that if anything needs to be changed to meet the changing needs of the customer, it can be. In every project I have worked in I have had to change someone else's code, I couldn't imagine how tedious it would be to have to get permission from another coder to make those changes.
Continually integrating your code into the project makes it very easy to see who introduced a bug, therefore who should fix it. After working on each new feature I run my entire test suite. The goal is to have 100% of the test pass 100% of the time. So when I start working on a feature the test should be passing both before and after the feature is implemented. Continuous integration also helps to reduce collisions making deployment an easier process.
The 40 hour week is a concept of XP stating that you should come in fresh in the morning and leave exhausted in the evening. Constant overtime can be a sign that something isn't going very well in the project. I don't always get exactly 40 hours on my timer, due to parts of the day that are not exactly billable to the customer, but I do manage to spend that much time in the office learning or putting effort into some project. It is increasingly more difficult these days to divide home life from work life. I have had calls from clients asking me to deploy features on the weekend. I will do it of course, but I do try very hard to keep a clear division from home life and work life, so that I come in feeling refreshed and ready to go each day.
An On-Site Customer is exactly what it sounds like. A customer sitting with the team answering questions and resolving disputes about the functionality of the application and its interface. We very seldom have this opportunity, but we do our very best to keep an open line of communication between the developers and the customer. I usually use technologies such as Trello, Skype, conference calls, and GoToMeetings to keep that line of communication open. An On-Site Customer would be better, but leveraging technologies efficiently is the next best thing.
Coding Standards ensure that code is uniform and concise. It should be difficult to tell which one of your team members wrote a specific line of code. A good coding standard should include DRY code (DRY means Don't Repeat Yourself) and Intention Revealing Names at a minimum. The key is that the code communicates. The rule at RoleModel is that two sets of eyes see (and approve) all production code. I love when good coding standards are in place. When the code follows a set order it is usually easy to add new features and functionality. I was surprised when coming to RoleModel with how high the code quality is. Seeing these high standards has helped me to become a better developer.
It is not the merit of the individual practices that makes XP so great, but rather the combination of them. If you tried to focus in on only one of these practices, parts of your project would fall through. When each is applied appropriately, it creates a certain synergy. I am very pleased to have been introduced so early on in my development career to a studio that implements XP principles, and I look forward to learning and applying everything I can from this experience.
Source: Extreme Programming Explained (Embrace Change) by Kent Beck, Pages 53 – 70.
