XP Days at Spotify


Screen Shot 2015-10-30 at 1.08.46 PMToday I had the pleasure of hosting the second day of a two day XP style workshop with some incredible developers at Spotify. Here’s what we did.

Build something fast!

We kick things off by asking the class to build a Reverse Polish Notation (RPN) style calculator. In 10 minutes.

We do this partially by design – to create a little stress. But it’s also an ice breaker. Just to verify everyone’s machine is up and running. As well as gauge the experience level of the class.

We then have a discussion about what some of the challenges are when building software. As well as what quality means, and how we can shoot for that in our software.

The birth of XP

This then segues into the birth of XP. Here I share Kent and Ward’s original vision of what XP was. Talk a little about the C3 project. And basically explain the XP attitudes behind if certain things are hard, we are going to continuously do them, all the time. Testing, integration, pairing, design, etc.

I also draw the cost of change curve and share how Kent wanted a way to develop software, such that the cost didn’t increase exponentially over time.

Screen Shot 2015-10-30 at 1.08.55 PM

Elephant Carpaccio

Partly because smaller stories are a good idea, and partly because it helps them with the project they do on day two, we then do an Elephant Carpaccio story slicing exercise.


This is great because it reminds people about what makes stories valuable in the first place, while also giving advice on how to slice. Basics, but really good stuff for people who may not have read or had any story training.

TDD together

This is where we formally introduce TDD, and revisit the RPN calculator we built at the beginning of the course.

As a class, I start with one other person, showing them the mechanics behind writing the test first, making it pass, and then … sometimes refactoring. Sometimes I don’t refactor, just to let the duplication build up and save for conversation later.

But we do this as a group, and it gives students a nice intro on a codebase and a problem they already know.


Something that’s surprised me as a middle aged programmer (cough) is how many people still haven’t read Martin Fowlers seminal book on refactoring. I have a lot of fun with this.

Refactoring, even in really tight circles of programming, is still a very misunderstood term. Usually it just means rewriting code. But people don’t appreciate always that when you are refactoring you aren’t adding any new value. You are only improving the existing design.

So I really hit home that the reason why that word appears in a menu at the top of your favorite ID is because of this book. And then I ask how people refactor without unit tests.

It’s a trap of course. Because you can’t. But a lot of people still do. So we talk about that.

So that’s day one. And during the day we also sprinkle in discussions about YAGNI, production readiness, and other XPisms and attitudes.

Code me a game

Day two is all about putting TDD, unit testing, refactoring, continuous integration, collective code ownership, and pairing all into practice. In teams of four, the class then goes about building a text based adventure game.

Screen Shot 2015-10-30 at 1.12.24 PM

Text based games are great for learning TDD. They are fun, most people understand how they work, and they don’t contain a lot of hairiness. But they contain enough hairiness to give a taste of what applying TDD in the real world is like (like how do you handle all those input output streams?).

We have a few rules for the text based game we are going to build.

  1. No production code without a failing unit test.
  2. No code not written in pairs.
  3. Refactoring happens continuously while the code is being developed.
  4. Check in early and often.

Screen Shot 2015-10-30 at 1.14.34 PM

It’s really fun seeing how teams of x4 tackle handling a new code base. We also have the challenge that many people come from different parts of the world. So everyone has their own keyboard which can make pairing tricky.

But people overcome. We have lots of discussion about how to test, how to design, and how to tackle all the hairiness that seems to come with coding, even on a simple text based game.

We usually do x3 one hour iterations. With a demo, code review, and discussion at the end of each.

We also track number of commit, number of stories, and code coverage.

After three to four hours people are pretty pumped and exhausted. We then sit back and reflect on what we’ve learned.

It’s really interesting watching people try TDD for the first time. On the surface, when you see other people do it, it looks really easy. But it’s not. At least at first. It’s hard. It goes against everything not only everything you’ve been taught in school. It also not the natural state for people who are just used to hacking.

But once people get it, you can see a light go one. They design their code differently. They find they need less code. And it takes a lot of the guesswork away. They only end up creating what they need. And for many that’s a revelation.

Of course TDD is only one leg of the XP stool. And all the other practices also come into play – particularly pairing. People often ask how do you keep the discipline up. You play a big part of that I say. But your pair can help you too.

Insights, Actions, and Histories

We wrap up the day with Insights, Actions, and Mysteries. Here we ask people what they learned, things they want to do, and things we still wonder about.

Screen Shot 2015-10-30 at 5.09.06 PM

Screen Shot 2015-10-30 at 5.09.15 PM

Screen Shot 2015-10-30 at 5.09.22 PM
Big insights today were the awesomeness of pairing (you can learn a lot working with someone else). Actions were YAGNI – try hard not to over engineer. And mysteries were things like how fast to move when doing TDD vs going really slow and gearing down to really really small tests.

Overall it was a great day. I always learn as much if not more than the attendees. And this was a great group to work with. See you out there!

Screen Shot 2015-10-30 at 1.13.53 PM


YAGNI vs Usability

Leave a comment

YAGNI (You Aint Gonna Need It) is a reminder to all who write software not to over engineer your designs, keep things simple, and add complexity only when necessary.

Usability, on the other hand, is about improving the users’ experience with the software—additional architectural complexity be damned!

YAGNI vs. usability are two forces that sometimes bump on agile projects.

This post looks at a simple example of how these forces can conflict, and how teams can help find the right balance for their project.

Keeping it simple

My last project was a web based application that showed users at a construction site which roads were closed on any given day.

One of the stories was called display road closures and the first version of the story looked something like this.


With a simple date based search at the top of the screen, the user simply enters the day they are interested in seeing road closures. They hit the search button, and the map refreshes showing which roads are closed, along with the search results at the bottom.

Delighting your customer

During development, my partner came up with a better way to visualize which roads were associated with which permits. Instead of simply displaying road closures in red, why not give each road closure a different color. And while we are at it, why not make the search results selectable—so that when the user clicks on a road closure at the bottom of the page, the associated road on the map becomes more bold and visible to the user?


I thought his idea was great. It required a fair bit of custom JavaScript, which would add some complexity to the UI. When asked how long he thought it would take, he said about an hour. Thirty minutes later it was done and integrated into the code base much to the delight of our customer.

Playing the YAGNI card

Deciding whether or not to implement this feature was a no-brainer. My partner had the necessary JavaScript chops, the cost was minimal, and our customers loved it.

But what if the trade-off wasn’t quite so black and white?

What if we didn’t know JavaScript?
What if the improvement, compelling as it was, was expensive to implement?
What if making the necessary change did require some heavy architectural lifting?

How should teams balance the desire of keeping things architecturally simple, with a desire to delight their customers?

See how you are tracking

Before getting all hot and bothered about whether to invest in an enhancement, or add a new feature, check and see how your project is tracking.


If your team is struggling to deliver stripped down, spartan versions of your customer stories as is, spending additional time on UI improvements is a luxury your project can’t afford.

On the other hand, if the team is on track, and the customer is happy with what they are getting, there may be a little wiggle room to make a few usability enhancements here or there.

And if your team is delivering ahead of schedule, all options are open. Go ahead and try the 13 shades of blue.

Know your project context


Every project is different. And not all have the same requirements around things like usability.

For some projects, a few fields and a submit button are more than enough. For others, nothing less than an aspirational experience will do.

Knowing ahead of time what your project requires, and how your customers feel about stories being ‘good enough’ will tell you whether you need to spend more or less on usability and the experience of the user. Putting working software into your customers’ hands sooner rather than later will serve you well.

Don’t be dogmatic

While YAGNI is certainly a sound architectural principle, like any sound principle it can be taken too far. When YAGNI is repeatedly used as a trump card to prevent improvements to user experience, it can upset team members, and cost the team an opportunity to better serve their customers. Not all usability enhancements need to be expensive, and sometimes the smallest of changes can make the biggest of impacts.

Like most things in life, it comes down to striking the right balance. The only way you’ll find out is if you build something, show your customers, and get some good solid feedback along the way.

Until then, you’re just guessing.

%d bloggers like this: