Posted: Jun 11, 2012
in general

By Felipe Iketani

The Power of Pair Programming

I’ve never programmed in pair. Two developers sat down in front of a single computer and they code together with one as the pilot and the other, the co-pilot. But in the last weekend I’ve joined in a local event in Brazil organized by my community that mainly studies and practices Agile principles.

During the event, I’ve led a Coding Dojo using Ruby to solve a Fizz Buzz game. That was my first Coding Dojo I’ve ever participated in!

Summarizing… the rules of Fizz Buzz game are like the following:

  • If a person’s number is a multiple of 3, he must say “fizz”
  • If a person’s number is a multiple of 5, she must say “buzz”
  • If a person’s number is a multiple of 3 and 5, he must say “fizz buzz”
  • If a person’s number isn’t multiple of 3 or 5, she must say the number.
  • If I make a mistake, I drink! This is the best part. :)

So before the Dojo started, I coded by myself what I thought the final code could be, just for practice.

I got the following specs:

So my own code:

Well. I did it alone, and I thought it was beautiful! Simply beautiful! Why? Because the specs say just the truth. They show us what the code should do. I could read the test and be just fine. Note that the spec descriptions are almost the same as the rules list I showed above.

Then the Dojo began. Half of the participants were new even to Ruby, but were at least a developer in some other language, but none of them was used to TDD.

Anyway, the code began. I started and sat down in the pilot’s chair and I was half coding, half teaching about good practices of programming, especially TDD.

I wrote all the specs, it was enough, but my 5 minutes were gone and I just wrote the first implementation of Game: when the number is multiple of 3, returns “fizz”.

Then a friend of mine took my place and some one in the audience took his co-pilot place. Then after about 1 hour, we’ve got the following production code (the specs weren’t changed).

I was simply amazed: this code was better than mine! If you check this new code, you can read the class just like the bullet list I showed you about the Fizz Buzz’s rules! Fantastic!

Then I was the last to sit in the pilot’s chair, and I improved the code a little bit:

What do you think about this last version of the code?

Yes, we could use “number % 15 == 0″ in the .number_is_multiple_of_3_and_5? method, but we didn’t, we just didn’t think about it at that moment.

But note the main improvements:

I’ve set the methods that use math to private, so the Game class interface just shows what the class should do: run the FizzBuzz game without knowing how it does it.

I have also improved the if/else syntax. Now the Game rules are perfectly readable in the specs and also in the production code! Couldn’t even a non programmer read the production code? Beautiful!

I try to get rid of IF when I code, that’s why my first implementation of the code I did for the Fizz Buzz game had less IFs. But I got rid of the most important: readability, even if it has more IFs.

Thanks to the Coding Dojo dynamics, the code became cleaner and more beautiful, even more so than my first code attempt.

Did the Coding Dojo finish after the event? I’m glad it didn’t!

After showing the code to friends in Webbynode, we refactored the code to the following:

Now we improved the private method names to fit the purpose of our Game! It’s readable just like the last one, but now we can inherit from Game class and create a new game class that uses multiples of 4′s and 7′s if you wish! Have you ever heard about the Open Closed Principle?

In the future, the maintenance would be easier, faster, cheaper and more enjoyable.

This is the power of Pair Programming.

Webbynode is Web Application Hosting for Developers Lean more .

Leave your thoughts

  • Steve Holmes

    I disagree with your conclusion.
    Your original code is far better to me.

    Let’s say we get so good at the game we no longer make mistakes, so we need to add another number. So if you could go back to the code and add “wizz” whenever it’s a multiple of 7, you’ll see yours is much much easier to amend and the second is not.

    (I like pair programming but I don’t think the above is a good example of it)

  • Caike Souza

    Nice, Felipe!

    @4db92af4bd8648748856c590ceb4e040:disqus , what I understand as being a benefit is that in the first version of the code, he would have to add a line with the implementation that checks for ‘wizz’, like so:

    return “wizz” if number % 7 == 0
    Although this works, I think they were going for something more expressive, which is:

    return “wizz” if is_wizz?(number)

    This would encapsulate the logic behind ‘what is a wizz?’ behind another method, rather than expose it to the Game.fizzbuzz method. 

  • Steve Holmes

    Yes, but you haven’t completed the final example. If you add the wizz for 7 then following the same style it needs a fizzbuzz method like this:

      def self.fizzbuzz(number)     return “fizz buzz wizz” if is_fizz_buzz_wizz?(number)
        return “fizz buzz” if is_fizz_buzz?(number)
        return “fizz wizz” if is_fizz_wizz?(number)     return “buzz wizz” if is_buzz_wizz?(number)
        return “fizz” if is_fizz?(number)     return “buzz” if is_buzz?(number)    return “wizz” if is_wizz?(number)    return number
    end

    then you need to define all the new methods.
    Also if you implement these as in the example you have something like

    def self.is_fizz_wizz(number)  
        number % 21 == 0
    end

    And if you want to change the value of buzz from 3 to something else you have to go and edit multiple methods – violating the DRY principle. Also not only do you have to edit all the places where 3 is used you have to go and work out all the places as it’s hidden in the magic numbers of 15 and 21.
    It’s not just a code smell it’s a code stink bomb ;)

    Surely you can’t think all of that is better than that one line edit for the original version.

  • Anonymous

    Interesting points of view, all of them. A careful look and considering @4db92af4bd8648748856c590ceb4e040:disqus approach, I’d use the predicates on the first solution. The nature of the problem is more approachable through your example, and so it fits better. 

    Adding a `wizz?` method and appending `”wizz” if number.wizz?` (something alike) would be elegant IMO.

    Good stuff, Felipe. A good example of how there’s more than way to solve problems and how to assess them according to their nature.

  • No

    in Ruby, the coding standard is to use fizz?
    instead of is_fizz?
    since the question mark already indicates you are asking a question

  • Felipe Iketani

    good point ;) it is indeed!

  • Sora

    IMO the code is poor :
    1) is_fizz_buzz? isn’t based on fizz nor buzz, so if you change one you have to change fizz_buzz (big architectural problem here considering the size of the code)
    you should at least make is_fizz_buzz? into the following
    is_fizz? number and is_buzz? number
    2) the point Steve Holmes said : if you have to add a condition you end up with much more code and have line such as return “fizz buzz wizz”
    you also have close to n^2 functions oO
    3) just my thought, but a pattern strategy would be nice
    4) is_xxxx? should be preferably xxxx? (or is_xxxx)

    Applying everything you end up with the following :
    class Game  attr_accessor :condition def initialize (condition) @condition = condition end def fizzbuzz(number) ret = “” ret << "fizz " if @condition.fizz? number  ret << "buzz " if @condition.buzz? number return number if ret.empty? ret end endclass Condition def fizz?(number) number % 3 == 0 end def buzz?(number) number % 5 == 0 endend

    —
    I didn't wanted to use an array so I simply put a space between each strings ;)

    Good : -anyone can easily change fizz and buzz condition by inheriting Condition-size of fizzbuzz don't "explose" if you add others rulesCons:-one more class :/

    Try it with :
    game = Game.new(Condition.new)(0..30).each { |i| puts game.fizzbuzz(i)}

    =)

  • http://dharmaprogramming.wordpress.com/ Denommus

    “and” and “&&” are not the same thing on Ruby:
    http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/ 

  • http://mwilden.blogspot.com Mark Wilden

    I would not have chosen any of these solutions. The first solution is closest, but it’s just a bit too clever in its use of concatenation.

    I would have coded it exactly as it was stated – an IF statement with four clauses. That’s the simplest solution that could possibly work (it’s also the easiest to write, test, and understand).

    Then I’d cross that item off my to-do list and find something else to do.

    IF and ONLY IF there arose a need to make this game more flexible, that’s when I would refactor it.

    But the refactorings as shown simply obscure the actual required functionality behind unnecessary abstraction. And a statement like “return “fizz buzz” if is_fizz_buzz?(number)” shows obvious duplication that should be a tip-off that the refactoring has introduced problems that didn’t exist before.

  • Leonardo Siqueira Rodrigues

    Doing:

    def self.is_fizz_buzz?(number)
    is_fizz?(number) and is_buzz?(number)
    end

    Mantain the code more simple [IMHO].

blog comments powered by Disqus