Before becoming an official part of Auctionet, there was a development team known as Barsoom. I've known the team for several years now, even before Kim joined it in 2012. But since before that they've been working one way or the other with Ruby and with online auctions.
My visit had been well prepared. I received a welcome mail with useful tidbits of information the week before and upon arrival, I found that a chair had been prepared for me with some much needed survival gear.
Greetings and tea grabbing done, I sat down with Henrik to work on an
Remitting Remit for review
After lunch Henrik suggested reviewing code before we continued on our task, and admittedly I was quite curious to see how the team's code reviews worked in practice. You see, unlike most other teams that I've encountered, where development is done in branches, the Auctionet team mostly commits directly to master. Also, instead of reviewing a branch before merging it into master, code reviewes are done after the fact, on a per-commit basis. To support this particular workflow, the team is using the Remit tool that's been internally developed.
Using this approach to code reviews for only an hour and a half is too short to draw any meaningful conclusions. While first impressions have a tendency to last, they also have a tendency to greatly lie. I'd be loathe to embrace of refute alternative approaches to what I'm used to after anything less than extensive use.
That said, I noted that within the team there are differing opinions on how the non-branching, post-integration code review process is working. Some of the arguments against it seemed to be centered against getting unwanted feedback on things that are far from done as well as reviewing the several iterations of the same code base when it's only the final one that really matters, i.e. potentially being wasteful.
Personally, I think one of the proposed gains of reviewing every commit - being able to early point a coworker towards a better solution - only works if the team is more or less continously reviewing commits as they are pushed to the master branch. I'd rather pair (or better yet, mob) to acheive better solutions, though coupling that with some form of code review of the finished work doesn't hurt.
All in all, it's intriguing to see a team doing something different.
Wrapping up the sprint
As I had joined the team on the Tuesday of the second week of a sprint, the plan was to spend the first two days working on tasks and the last two days partaking in their lab days. Thus, on the second day I continued working with Henrik until lunch, after which I joined Tomas and Joakim who were adding tests for a React component. The next day would start with a retrospective, and as had previously been suggested, I would get to facilitate it.
I had mostly planned the retro before going to bed that night, but as Kim and I sat on the bus the morning after, I got some inspiration from a most unexpected source: car registration signs.
MWD 123...hmm...that reminds me of something.
And thus, with some reordering of letters and some alliteration, a retrospective format took shape in my brain.
Testing the exercises on the team proved most valuable to me as it refined the format. It also proved fruitful to the team in the sense that three distinct tasks came out of it. An added challenge was making the format work for the team's remote worker in London, Victor. We made do by having me transcribe his notes to post-its and showing him the board while allowing the rest of the team to take a short break.
Before breaking for lunch, there was one more thing that was divulged to the team; Victor would leave by December. Despite the best intentions, working remotely from home was taking its toll and the need for more social interactions outweighed the desire to stay with the company. Naturally, several emotions surfaced at this. I've yet to see a team that isn't somewhat taken aback by the news of a team member leaving, nor would I want to see one.
No gin, but some Toniq
Nevertheless, Joakim and I went to town on Toniq as previously planned. Toniq is an Elixir background job library using Redis not as a queue, but rather as a backup and failover mechanism. For the next day and a half, we paired on adding the failover functionality. In broad terms, multiple Elixir nodes might be processing whatever background jobs that have been directly sent to them, but if one goes down, another node should pick up the orphaned jobs. This isn't handled by a supervising node, but rather cooperatively. By continuously updating and checking "keep alive" keys in Redis, a node can detect that another node has gone down. If so, it will attempt to take over the downed node's background jobs. Since that is done in a Redis transaction, there's no risk for two nodes both taking over the orphaned jobs.
Why would one want to use Redis in this capacity instead of relying on the battle-proven failover mechanisms of Elixir and Erlang? Well, given the number of Rails shops deploying their code to Heroku, some of the niceties simply aren't readily available. Where Elixir/Erlang nodes can remain running for years at end, Heroku still reboots a node every 24 hours. I believe that either Heroku will provide better support for Elixir and Erlang in the future or someone else will.
Pairing with Joakim was a pleasure. We hit a good rhythm and as both of us are avid fans of Elixir, it was especially fun to build something directly useful to the company in that language. I'm looking forward to hearing Joakim introduce Toniq to the Stockholm Elixir crowd at our next meetup.
Rounding out a pleasant stay with the team, we stayed late at the office on my final day for drinks and a movie. Cheers for having me!
For details on the retrospective format used, see Weapons of Mass satisfaction.
For more information on the code rewiew practices of the team, see Henrik's blog posts The risks of feature branches and pre-merge code review and Pair programming is not a substitute for code review.