Last week, a group of us did an XP Tech Practices workshop here in Stockholm. We covered Test-Driven Development, Refactoring, Unit Testing, Pair Programming, and a host of other Old school XP practices. Here are some notes and a write up about the course.
What is XP
XP (Extreme Programming) was the first really popular Agile method. Not only did it introduce Agile planning concepts such as user stories, adaptive planning, and iterative development. It helped popularize engineering practices such as unit testing, refactoring, test-driven development, and continuous integration.
It isn’t as widely practiced today as it was in the early 2000’s (Scrum has largely taken over). But it has many wonderful practices and ideas that deserve repeating and are still very much relevant for software teams today.
This workshop aimed at revitalizing some of software these practices, showing participants who they were originally meant to be performed, and then discussing how they can be introduced into their workplace.
How do you feel about your work?
We start off the course by asking participants how they feel about their work. Specifically around quality and design. We do this to start a conversation around what quality is, how we know when we have good design, and what obstacles prevent us from reaching them in our software.
We then break the ice by asking participants to code something up (like a calculator). We do this to get the juices flowing, engage the participants, and just get them hacking. This helps us see where they are coming from, their familiarity with the programming language, and how comfortable they are writing code.
We don’t judge or do anything with the code that we produce here. We simply park it, and revisit it later. We then introduce XP.
XP can best be described as the software methodology that turns the knobs up to 11.
If code reviews are good, we will review code all the time (pair programming).
If testing is good, we will test continuously (acceptance tests, unit tests, TDD, demos).
If design is good, we will design continuously, every minute and every day (refactoring).
If simplicity is good, we vow to always leave the system in its simplest state.
If integration is good, we will integration continuously (continuous integration).
And if iterative development is good, we will iterate from day one, continuously getting feedback on our product, plan, and ability to please our customer.
Once we’ve covered the spirit and intent of XP, we demo the practices. We pair program up a sample problem, applying TDD, refactoring, unit testing, and pair programming in an extreme way, just to give the participants a sense of how all the practices work.
We then revisit the exercise they did in the ice breaker, and try it again, this time using the XP practices, specifically writing the tests first.
Build a game!
We then unleash them on their own codebase – specifically a game. They take what we’ve covered, and apply the practices in as an extreme a way as they can, and we build a fun interactive game over the course of several iterations.
Over the span of the course we look for opportunities to introduce XPisms. Things like:
YAGNI – You aint gonna need it. A reminder to keep things simple, and not add excess functionality / code unless absolutely required (a good test is whether you can write a failing test first before adding the new code).
Production Readiness – A system spends a lot more time in production than in development. So why don’t we start treating it that way, and write code as if we were in production from day one.
Doing the simplest thing that could possibly work –
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. – C. A. R. Hoare
Test everything that could possibly break – We can’t test everything. But we know we can’t test nothing. So we start by testing everything we think could break. And evolving our suites from there.
Dials to 11 – XP’s take on hard problems is to take them head on. Taking this approach takes many of the traditionally hard problems on software projects, and breaks them down into much smaller, easier to digest pieces.
Courage – Have the courage to write that failing unit test. Have the courage to say no to the hack on your finger tips. Have the courage to say no to the unrealistic schedule, and help another team out when they really need it.
Why we feel this is important
It may seem that XP is all about engineering. It’s not. It’s just as much about culture. But the culture XP wants the team to operate under doesn’t happen if certain practices aren’t in place. This course is about explaining the practices, showing how they work, and then helping teams adopt them their work place.
A special thanks to Henrik Kniberg for the initial course outline and for his support in making this course happen.
“I was supposed to have a Hackday today, but this is WAY better”
“I found the course to be a lot of fun, and learned a lot about TDD/XP in the process. The exercises, particularly the four-part exercise to build a game for a customer, were a very good balance of difficulty and fun, and allowed me to learn at a good pace without being bored by trival tasks or overwhelmed by difficult ones.
In fact, the game task actually, perhaps accidentally, was almost tricking me into learning stuff. You know you give a kid a toy that’s actually teaching them maths without them knowing because they’re having fun with the flashy lights? It was kinda like that.
★★★★★ Five stars, genuinely one of the best in-house workshops I’ve attended.”
“Got a good amount of new perspective on XP and TDD. Got into the habit of writing unit tests during instead of after development. And it was a lot of fun!”