Category: Experiment

Another Way to Write Ruby Code

Disclaimer: I am not suggesting to change the Ruby style guide.

At a workshop I was giving a few years ago, someone not used to writing Ruby code found an interesting way, that you can write Ruby code.

First let’s assume a class Thingy, that doesn’t do anything useful. It’s just needed to demonstrate the way to write Ruby.

Assume this is in file ‘thingy.rb’:

# frozen_string_literal: true

# Thingy is only used to demonstrate
# a way of writing Ruby code
class Thingy
  def initialize(*args)
    @args = args
  end

  def this(other)
    @args << other
    self
  end

  def that(*other)
    @args << other
    self
  end

  def content
    @args
  end
end

Now, let’s use this class in another script, that’s showing the alternative way to write Ruby code (in file use_thingy.rb):

# frozen_string_literal: true

(require_relative 'thingy')

part = (Thingy.new 'String', :symbol, Math::PI)

(p ((part.this 'Wahoodie?!').that :huh, Math::E).content)

Notice that rather LISP-like way to parenthesise, in line 7 in particular. I still am surprised that this is possible in Ruby and actually behaves the way I’d expect.

Running that script yields the following output:

> ruby use_thingy.rb
["String", :symbol, 3.141592653589793, "Wahoodie?!", [:huh, 2.718281828459045]]

It’s also entertaining that Rubocop does not complain about this code:

> ls
thingy.rb     use_thingy.rb
> rubocop .
Inspecting 2 files
..

2 files inspected, no offenses detected

This is one of the reasons I like programming in Ruby so much: One can discover new ways (even if probably not very useful ones, sometimes) even after years of using it.

In case you’d like to experiment with this code: It’s on GitHub: https://github.com/s2k/alternative_way_to_parenthesise_in_ruby

Expressing Expectations

Long long ago, while preparing experiments for my diploma thesis in physics, my tutor taught me to express my expectation of the outcome of experiments before actually running them. I was to not only to express them in my head, but speak them out loudly, may be even make a note.

This helped a lot, when figuring out where my thinking didn’t match the experimental evidence. There was no denying when my expectation differed from the empirical result. Typically, there were two sources for the differences:

  1. My mental model wasn’t good enough to match the result of an experiment.
  2. The experimental setup wasn’t designed well enough to show the effect I was trying to measure.

I find that this is still working well in software development (both the coding part as well as testing). A related article about this is Peter Naurs seminal paper ‘Programming as Theory Building’.

When doing TDD (test driven development), explicitly expressing the outcome before running a test may not always lead to a surprise. In the very beginning, when a test tries to create an object, without having a class definition, it will cause an error message that is easy to predict.

However, when work has progressed a bit, I regularly run into situation where I expect the next new test to fail in a certain way, but when running the test, the actual error message is a surprise to me. These are situations where learning can happen, by figuring out why the actual behaviour does occur, instead of what I predicted.

Near the end, the surprise is caused differently: I’ll write a new test and expect it to fail. – It doesn’t. Again, this is a good reason to explore why exactly I thought the test would fail.

Particularly in a pair (or ensemble) programming setup, the inability to come up with a new failing test is a sign, that the implementation is good enough … for now.

Recently, I did a programming exercise as part of a technical interview, and expressing my thoughts and expectations while working on the code helped me to find a solution. Additionally, the interviewer didn’t only see what I was typing, but could follow my way of thinking. This relates to Naur’s paper mentioned above: The testing and tested code I wrote isn’t everything there is to my mental model of the given problem or its solution. The way of thinking is important too. This is why I find vocally expressing my expectations & thinking while actually doing the work.

What are your preferred way to actually do the work you’re doing? I’d love to hear about it.

The Agile Testing Days 2014: Conference Day 2

The first keynote of day 2 “Test First Saves The World”, was Joe Justice who talked about applying Scrum in non-software industries, including the automobile industry. He also presented a very exciting project which attempts to build a car: http://wikispeed.org/car/

In fact, he brought parts of a car and invited the conference attendees to join a Scrum team and build a car in the hotel lobby.

People building a car in the hotel lobby
Building a car at the Agile Testing Days 2014

Joe also pointed to another project he started: The MicroHouse, that aims to provide a clean bathroom, a clean bedroom, a lockable front door at less than 100 USD. It is this project that is linked to the “save the world” part of the presentation title.

In the second keynote Fanny Pittack and Alexander Schwartz presented “Insights from Happy Change Agents”. Both of them have presented at previous conferences, but this time they went for a pair presentation and a keynote — even though they have never worked together before. I found this one very inspiring, to say the least. They demonstrated how a coach can take on the perspective of a team, rather than using her (or his) point of view from the outside. In addition to that, there was also a pair exercise for the attendees to do. They also shared their slides:

To me, the talk was not only about changing your point of view, but also about trust in a team as well as a single person. When the question session started, I made an unusual (for me) move and asked whether someone from the audience was willing to prepare a pair presentation submission for next year’s Agile Testing Days. Then two things happened rather quickly: First José Díaz announced, that if I find a pairing partner, then the session is already accepted:

How awesome — and trusting! — is that? The second thing to happen: The first person I noticed to signal willingness to co-present with me was George Dinwiddie. We met in person for the first time at this conference, have never worked together before and we’re separated by the Atlantic Ocean. I expect to have great fun and learn a lot while working on our presentation. I am sure that we will figure out how a distributed team (of two) can work.

Even now as I write this — a week later — I’m amazed, impressed and honoured by the trust and friendliness of all this. Thank you all: Every single one in the audience in general and George & José in particular!

After this, I had a short break from the ‘regular talks’ and attended the Open Space session (there were six of them, throughout the conference!) facilitated by Alex Schladebeck and Meike Mertsch. Since there were not too many people attending the sessions, we changed the format to a Lean Coffee. I like it a lot when a format is changed ‘on the fly’ in order to match the circumstances, instead of sticking to a plan that doesn’t fit well anymore.

Among other things, we discussed the question “What makes a good session at this conference?”, brought in by George and me, since we wanted to know what it is that people like about a session. Thank you for voting on this topic to everyone who attended!

The third keynote of the day was David Evans’ “The Three Pillars of Testing”. He explained how testing and agile fit together and placed just the right amount of puns into his talk. He explained the classic order of capitals, what ‘Euthynteria’ is — and what is isn’t:

Do not confuse euthynteria with 'youth interior'
What ‘euthynteria’ is — and what it is not

This was the end of a very pleasant and entertaining second conference day.

Breaking Stories Into Tasks With Meta Stories

In this post I present an idea we had in a meeting recently. I am not sure it’s a good idea and would definitely like to know what you think about it.

The Setup

One way to look at teams implementing stories is this: Stories are pulled from a queue, then implemented and finally handed over to ‘business’, to decide whether or not a story is put into production.

Stories flow from a queue thought the team into a state 'done'
Stories flow from a queue thought the team into a state ‘done’

In many typical setups there’s another process which is used to break down stories into small enough tasks which can actually be implemented. At some point there’s also a decision to be made about the order in which to implement the stories, but that’s not a topic of this post.

Often the breakdown is done in a whole-team meeting, which can be as long as half a day. The goal of this meeting is to find tasks for a number of stories.

The Idea

Avoid the ‘whole-team story-break-down meeting’ and instead have ‘meta stories’ which are put into the queue.  Each meta story is about cutting only one story into tasks.

  • Not all the team members have to work on this (although all can).
  • Meta stories are put into the queue whenever there’s a risk that the team might run out of unimplemented stories.
  • This is the main reason to give a high enough priority to meta stories: It’s in the very interest of a product owner (or however the role may be called) to provide enough work to the team.
  • As soon as the meta story is broken into tasks, it can be prioritised and put into the corresponding position in the story queue.

Questions & Leaving Thoughts

I personally think it’s worth trying, probably in the form of a time-boxed experiment. There should be a way to decide whether or not, much like J. B. Rainsberger describes it in this presentation on vimeo. The description of running this kind of experiment starts around minute 30, but really, watch the whole video.

Can this work? Will it work? Has anybody tried this before? If yes: In what context? What were lessons learned?

%d