Tag Archives: Dojo

A Step by Step BDD Demonstration with Some Useful Insights

Posted by on 2011/12/11 2 comments


According to Stephen Covey, the seventh habit of highly effective people is “sharpening the saw”. If you have ever been to an agile workshop or conference, you may have already heard this expression. Software craftsmen sharpen their saw at coding dojos where they talk to each other a talk about new things or do Kata exercises together. With Kata exercises a software craftsman trains himself to be better at software development. I’ve found two real reasons why people are doing Kata exercises: first, they want to be able to solve certain situations instinctively, and second, they want to make the right decisions when they work with real code base. The second topic is much more interesting to me, so I decided I’d do a Kata exercise and explain the background of every significant decision I make along the way.

I chose the English numerals exercise that we were doing at Digital Natives, with some minor modifications. The original exercise is very simple: the application shall receive a number, for example 1997, and it shall return that number in written form, i.e. one thousand nine hundred and ninety-seven. We added two things to the original exercise: the application shall be a ruby on rails application, and it shall support numbers from 1 up to 1,000,000,000. Besides the implementation I’m going to put more emphasis on the following topics and practices:

  • how the cucumber -> fail -> rspec -> rspec green -> cucumber green -> refactor cycle works
  • how to implement an algorithm with BDD/TDD
  • how to recognize large steps during development and how to break them down into smaller ones
  • when and how to refactor code and test cases

My first decision is that I will do BDD/TDD as described in the RSpec Book: my development will be driven by cucumber scenarios and I’ll use rspec for filling in the details and describing the algorithm I’m using for converting the numbers. And moreover, I won’t start the application until it is done – I’m curious whether it is possible to build a web application using BDD and never start the application itself.

Read more »

VN:F [1.9.13_1145]
Rating: 10.0/10 (3 votes cast)

Building a Bridge a.k.a Parallel Changes

Posted by on 2011/10/04 1 comment

Several days ago, we had a coding dojo at Digital Natives: we wanted to reimplement a method without changing its purpose. To do this, we used a technique called building a bridge, which is also known as parallel change. The technique itself is quite simple, and in this post I’m going to show you how to use it and why.

For example, I have this piece of code, which is presumably part of a larger code base:

class Foo
  # ...
  def count(first, last)
    counter = 0
    first.upto(last) do |i|
      counter += 1 if prime?(i)
    end
    counter
  end
 
  private
  def prime?(value)
    [2,3,5,7,11,13,17,19].include?(value)
  end
 
  # ...
end

Maybe it is not working very well – its limitation is obvious -, but it is more than enough for now. Let’s say that we decide to change the prime? method. The same method, the same purpose, only the algorithm will be different. So we create a new method called prime_next? and implement that method either with TDD or in a regular fashion. After it is done, we’ll have something like this:

class Foo
  # ...
  private
  def prime?(value)
    [2,3,5,7,11,13,17,19].include?(value)
  end
 
  public
  def prime_next?(value)
    # a fancy algorithm probably based on Fermat's primality test
  end
  # ...
end

When our tests or gut feelings indicate that the new method is complete, we replace the method names, so prime? will be come prime_next? and prime_next? will become prime? (hint: it is easier and safer to switch the actual method names than to change the references. For example, in ruby we don’t have a fancy IDE with the “rename method...” functionality so it would take some time until all the references are changed, not mentioning the expressions evaluated at runtime).

We run some more tests – or trust our feelings – so that we see whether the new algorithm is working with the rest of the code base. If everything is up and running, we clean up and deliver:

class Foo
  # ...
  def count(first, last)
    counter = 0
    first.upto(last) do |i|
      counter += 1 if prime?(i)
    end
    counter
  end
 
  private
  def prime?(value)
    # a fancy algorithm probably based on Fermat's primality test
  end
  # ...
end

This was the “how”, but it seems a lot of unnecessary work for a change, doesn’t it? It may seem like that at first, but I prefer to do it, because it ensures that while I’m working on my changes, I can still work with the rest of the team, and that the code I’m working on is well tested. Now, let’s see the “why”.

Read more »

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)

Code Review During Retrospective

Posted by on 2011/08/02 4 comments

Most of the retrospectives I’ve kept or participated in were about agile approaches (for example communication with the Product Owner) and organisation-related changes, but not everybody is into these. Most software engineers and craftsmen aren’t that interested in how to deliver faster, or how to communicate better, they are interested in how to be better at their profession: programming.

Usually, software craftsmen are interested in new technologies and improving their programming skills. The easiest way to gain knowledge and improve skills is to learn from each other, see how others are programming, what kind of tricks they are using, what problems they have, and how they solve them. Last but not least, when you read other people’s code, you will have more information about what is going on in the project(s) you are working in.

My proposal is to do code review during your retrospective meetings.

Usually, this kind of retrospective has the following goals:

  • learn new programming techniques
  • find quality improvement ideas
  • find coding behavioural patterns which need to be kept
  • find coding behavioural patterns which need to be changed

It is really important to keep these goals in mind, because the retrospective is not a real code review session where the goal is to find mistakes and correct them. It is about finding those things which can make you a better craftsman in the long run.

Read more »

VN:F [1.9.13_1145]
Rating: 8.5/10 (2 votes cast)

Weekly – CW18

Posted by on 2011/05/10 1 comment

I’m still a bit busy, but nevertheless here is the collection for calendar week 18, 2011:

  • Most of the agile articles are about success and good things, which makes the whole agile initiative a bit mythical. Therefore I was happy to read an article, which makes the whole thing a bit more realistic: Jacub Holy tried to refactor  a huge class from Hudson. Although it is not a success story, it is a good reading, because there several good ideas and takeovers in it.
VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)

Weekly – CW12

Posted by on 2011/03/28 No comments

I usually exchange interesting articles, presentations and links with my friends in many different ways. I thought it would be better to use one simple way, so I’m going start a weekly series where I post articles, presentations and links I read during the week and find interesting. So here is the collection for calendar week 12, 2011:

  • Google was always famous for innovation. Patrick Copeland presented the eXtreme innovation approach – used by Google -, in his Keynote at QCon 2010. Pretotyping seems to be a good way for implementing only those ideas that really matter. It also helps not to spend time and money on ideas that people will hardly ever or never going to use.
  • My average e-mail inflow was approximately 90 e-mails per day and I read about 5 of them. I was happy to read an article about how to write e-mails effectively. If everyone who wrote to me, had read this article and had written mails as the author had suggests, I might have had the chance to read all of them.
  • Last but not least, here comes a great post about handling waste properly in lean systems. As usual, waste elimination is not black or white. A good lean/Kanban team (or team leader) should be able to recognize the nature of the waste, and eliminate what is really unnecessary.
VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)