Launching iMessage on Spotify

Leave a comment

This week, a project me and my friends here in San Francisco have been working on finally went live. The Spotify iMessage App Extension.

Screen Shot 2017-08-04 at 1.25.07 PM.png

This app extension let’s you search for songs, send them to friends, and then play short 30 sec clips.

Sep-15-2017 08-14-06.gif

I know it doesn’t look like much – but it was a lot of work! You’ve got just the basic functionality of the App itself. You’ve got error handling. How to handle going off line. Analytics. Authorization. The expand and collapse interaction of iMessage. Nasty bugs. And the requirement to support both portrait and landscape orientations too (thank you UIStackView).

Sep-15-2017 08-18-08.gif

You don’t launch something like this without a lot of help. And I want to thank:

And my partner in crime, with whom this all started as a Spotify hackweek project, Joseph Baena.

Without them none of this would have worked.
So thank you team.
Onwards and upwards.
Looking forward to iterating more on this great platform!

Oh. And we are hiring! So if you are a mobile iOS or Android engineer, and have always wanted to work a great team in the great San Francisco Bay area, go checkout our job listings here and see if you’d like to join the band.

Links

Advertisements

XP Days at Spotify

2 Comments

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.

https://docs.google.com/document/u/1/d/1TCuuu-8Mm14oxsOnlk8DqfZAA1cvtYu9WGv67Yj_sSk/pub

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.

Refactoring

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

Launching Spotify on the Sony Playstation

2 Comments

Delivering a new product to 60 million users

Last week was an exciting one for me and my team here at Spotify. We launched the Spotify player on the PS3 and PS4 and brought the Spotify music experience to over 60 million PlayStation users. Here are some notes on how we did it.

How it was run

This was a big project – one that spanned many tribes and cut right across the entire organization. Marketing, sales, licensing, distribution, all of tech. It was also very distributed with Sony and Spotify teams spread across San Francisco, London, Stockholm, Tokyo, and New York.

Spotify doesn’t have project managers. But for this project we did appoint someone to play the role of an overall programme manager. This was key because there were a lot of moving parts, and someone needed to help coordinate.

We did several onsite visits. Many teams came to Stockholm. We went to Tokyo. And there were a lot of early morning/late night calls (not to mention a tonne of email and Slack chats). Every Friday we also had a standing lunch where anyone interested could get an update on where things were at along with the current problems we were facing.

My team was responsible for building the app that would run the Spotify player on the PS3 & PS4. Four developers, three QA, a designer, a Product Owner, and me the coach.

Challenges we faced

Spotify doesn’t normally do projects. Instead we prefer giving teams a goal, and then letting them decide when best to release. We didn’t have that luxury. Sony’s old music application was due to shutdown at end of March, and we needed to be ready with our player to take it’s place. So in that sense, this was a very traditional project with a really hard deadline.

How we overcame

We ran this project like a typical Scrum project, only we quickly resorted to a kind of code and fix mentality that often comes when you realize you have too much to do and not enough time.

In addition to playing coach I also played the role of project tracker (tracking things like our team velocity and keeping an eye on overall deadline). For pretty much the entire project things didn’t look good. We had too many features. Not enough time. Typical project stuff.

Spotify’s approach to situations like these is to leave the team alone and let them sort things out for themselves. If they want extra help it’s there. But really it’s up to the team to solve their own problems.

What was interesting on this project was that the team (mostly the dev’s) didn’t initially want any outside help. Even when it became apparent that there was too much to do.

There was an inflection point in the project were senior management insisted we take someone else on (a fourth developer). This turned out to be a very good choice. Our new addition ended up making an invaluable contribution and we wouldn’t have made it without him.

But this leads to an interesting question for management – how far should you trust the team, and how do you know when to step in and ‘overrule’ their judgement. It’s not an easy call.

Finally, and perhaps most importantly, the one thing we did have going for us is we were the #1 priority project for the entire company. This meant that whatever we wanted – we got. A project this cross cutting and of this size can’t be handled alone. And the entire company was needed to pitch in. So when we needed people, meeting rooms, resources, or just decisions, people on the team just pulled out these ‘magic’ project cards and things got done. It was a fun way to work. But one you must be careful not to abuse.

Finally, this project required a lot of overtime, weekend, and late nights to bring across the finish line. We made it. We delivered. But there was definitely a human cost in terms of time, capital, and technical debt.

The launch

Now for the fun stuff! Here are some pictures of the war room on launch day.

There was a lot of coordination and monitoring that needed to happen on launch day. We created a war room, with each team represented at their own workstation.

spotify-sony-playstation-1

We also had sample Sony Playstation on standby, so we could log in to different regions around the world and make sure things were working.

spotify-sony-playstation-2

We also had a real cool analytics team that specializes in tracking usage in real time around the world.

spotify-sony-playstation-3

The Apollo launch feeling was created by design. Several pictures a phones like these were in full force that day.

spotify-sony-playstation-4

And this is what things looked like just before launch.

spotify-sony-playstation-7

spotify-sony-playstation-8

We kept the war room going for about 48 hours. Once Sony pushed their package out to all the PlayStations, we slowly saw people start to come online around the world, and it was great to see no major hiccups or disruption our backend services couldn’t handle.

To be honest I was amazed. I wasn’t expecting anything to go smoothly. What isn’t easy to see is the amount of work that goes on behind the scenes to make something like this happen. So many things can go wrong.

But somehow it worked. It all came together. It wasn’t Agile. It wasn’t any process, or secret sauce. It’s that same old cliche – it was the people. The talented, passionate group that went the extra mile, stayed the extra night, and worked the extra weekend to make this thing happen.

In Summary

I don’t know if I will ever get to participate in an event of this magnitude ever again. It’s pretty incredible to see this much focused work come together in this timeframe, in a single effort.

But I am thankful to have been a part of it. And I want to thank my team for all their hard work and making it happen.

umbrella-team

Newsletter

If you like this newsletter, you can find more here:

http://www.agilenutshell.com/newsletter

XP Tech Practices Workshop at Spotify

1 Comment

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.

xp1

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.

Build something!

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 Intro

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.

XP Demo

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.

XPisms

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).

xp2

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

xp3

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.

xp5

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.

Quotes

“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!”

Copy with care

2 Comments

I understand the desire to copy others. I do it all the time. I read an article about Facebook having no QA department, or see first hand how Spotify delivers projects with no Project Managers, and I can’t help but wonder how if they can do it, why can’t we do it here?

There’s just one problem. Copying others is never that simple.

When we see or admire what one company is doing, we are only seeing it through the lens of the end result. And not the underlying foundations that were setup to get them there.

Facebook can get away with not having a QA department because of the huge level of accountability they place on their engineers. Not to mention the insane level of talent.

Spotify doesn’t have formal Project Managers. But it empowers, and gives a level of autonomy and independence to it’s teams, so that teams are inspired to manage themselves.

For fun, this is the conversation I imagine trying to have with the Oil and Gas executive back home.

“OK. For next year we are going to try something new. No annual budgets. When Toronto asks us how much we are plan on spending, we will simply say we are going to spend whatever the cost is for us to work here this year. Our burn. That’s our budget. And in exchange for that they will empower us to do whatever it takes to meet the goals we have jointly agreed upon and laid out before us.”

Needless to say this wouldn’t fly.

But that’s my point. It wouldn’t fly because most companies won’t give the trust and accountability necessary to get the level of commitment and passion they see and read about in others. For their employees it will always be a job.

So am I saying we should give up, stop looking to others to inspiration, and just accept that we work for companies that will never give us the levels of autonomy, accountability, and independence we crave.

Hell no. Just remember. Not everyone wants this level of accountability. For many people work IS just a job. And trust is something that needs to be earned.

So keep reading. Keep studying. And keep looking to others. Just understand. What works at Apple, or Google, won’t necessarily work out of the gate at yours. Don’t get discouraged, keep trying to make where you work a better place, because at the end of the day, what other choice is there.

Joining Spotify

7 Comments

spotify-logo-primary-vertical-light-background-rgb
Well, after a whirlwind summer, I can proudly announce I have joined Spotify as an Agile Coach here in Stockholm Sweden. I just completed my first week, and before entering bootcamp I wanted to share some thoughts, observations, and comments from week one.

Surface observations

Spotify, for those of you who don’t know, is a music streaming company founded in 2006 which today has about 40M active users and 10M paying customers.

The best way to think about what they do is to imagine having access to all of iTunes for free. You don’t download the songs. They are streamed to you in real time on whatever device you happen to be listening. Then for $10/month you can get rid of the occasional add – this is called the premium service. Spotify competes with Google and Apple in the music service industry.

Being a music tech company Spotify has some pretty incredible engineering talent. They have music players, iOS/Android clients, embedded hardware in speaker systems, not to mention some enormous scaling issues for when it comes to streaming music to people anywhere, anytime around the world. Very strong engineering.

They are also the most mature Agile shop I have ever had the chance of working with. They have been innovating in the Agile space for some time. Most of their challenges are organizational. Like how do we scale this thing.

For a good video on Agile at Spotify watch this.

http://vimeo.com/85490944

Sweden

This being Sweden, there is a strong culture of building consensus (similar to Japan). But different also in that there very little formal hierarchy. Spotify stress autonomy, and empowerment at a level I have never seen before in a company of it’s size. Every team here truly is a startup and empowered (and expected) to make their own decisions and follow through.

So overall, a very high-level of self awareness, a great deal of maturity, but an understanding that they haven’t got it all figured out (despite the number of daily tours and requests they give to other companies visiting the office, and asking them how they do it). They answer of course is there is no one way – this just happens to be the Spotify way.

Great challenges

Working here is also like having a front row seat to one of the greatest battles our industry is going to see – who is going to dominate music. Going up against the likes of Google and Apple is no small thing. And Spotify is well aware of the challenges they face.

Organizational scaling, reduced friction, iterating fast, and discovering the future before others have real meaning here. There are going to be some real challenges. And I feel very fortunate to be a part of that.

Coming soon

For my friends and family back in Canada stay tuned. Spotify is coming! There were some regulations from the Canadian government that needed to be sorted out before Spotify could launch, that that being complete Spotify should show up sometime I hope this year.

So stay tuned. Sign up. And listen to the music.

Cheers – Jonathan

Links

CEO Daniel EK Charlie Rose Interview

Personal blog of family life in Sweden

%d bloggers like this: