Tag Archives: programming

Visit at Cluj Napoca

Posted by on 2011/10/30 No comments

My old friend Victor invited me to Cluj Napoca, Romania to talk about software development in practice. There were three talks in the morning at his company evoline and a fourth talk late afternoon at the local meetup group.

We started the day with an introduction to Kanban, because the audience knew about Agile, but Kanban was something new, and additionally we needed it for the maintenance-related presentation:

After a short break we continued with a longer talk about maintenance and how to use Agile, Lean, Kanban and leadership techniques in order to stabilise a maintenance situation:

The last presentation was about how to use Agile techniques without saying Agile:

My talk at the meetup became a bit longer than I expected, but we had – at least I felt like that – a great discussion how the software development process evolved at Digital Natives – my current company – and, uniquely, we talked about what we were doing right and where we failed:

I promised a list of books worth reading. So here are they in a recommended reading order:

  1. Taiichi Ohno – Toyota Production System
  2. Henrik Kniberg – Lean from the Trenches
  3. Daniel H. Pink – Drive
  4. 37 signals – Rework
  5. David J. Anderson – Kanban

Even though it was a long journey and an even longer day, I enjoyed it very much. The audiences were great, and I got some very usable feedback on the style and content of the presentation (I’d like to specially thank Dragos, Cătălin and Victor for the detailed and more personal feedback), so I can improve my future talks. My next talk will be at my former employer Ericsson, and I’m going to talk about leadership and measurements.

Thank you folks for the possibility, it was my pleasure!

VN:F [1.9.17_1161]
Rating: 9.5/10 (2 votes cast)

Saving the Continuous Integration

Posted by on 2011/10/19 6 comments

I really like continuous integration, that’s why I’m always sad when I see one dying. Unfortunately, I’ve seen it happen a lot, and in every case its lifeline looked like this:

The introduction of the continuous integration is usually started by an enthusiastic team member who read about it, realized “it was cool”, and it was just what the team needed. She quickly affects the whole team, they set up the build servers and are really happy with it.

The first fracture happens when the first unexpected failed build appears on account of a test case failure. Nobody knows why the test fails, because it works locally, also works on the server, but mysteriously sometimes it just doesn’t work in either of these places. The team is aware of the phenomenon, closes the case saying “don’t worry, we know that sometimes it fails” and moves forward. As time goes on, the team adds more test cases, and another failing test case appears on the horizon. Mysteriously, just as before. The same decision is made, because a team can live with two known failing test cases, can’t it? Unfortunately, this question signs the death sentence of the continuous integration build, because failing test cases decrease the faith in the system, and team members will start ignoring the results, because they are not trustworthy. Criminologists call this phenomenon broken windows syndrome:

Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside. (source: wikipedia)

Occasionally, some of the team members pull themselves together and decide to “fix the build”. They might even get management support. Unfortunately, the broken windows are more powerful than them: while they are desperately trying to fix the test cases, other team members are going forward and building software based on an insecure base and creating more failing test cases: the broken windows are working behind the curtains. At the end, only the initiator checks on the build, because everybody else has already given up the fight with the windmills. This is the end of the continuous integration for the team: “flatline”.

For me, sporadically failing test cases are like diseases, and should be handled accordingly: until it is not known what the problem is, they should be separated from the reliable (healthy) test cases. If a team relies only on reliable test cases and keeps the unreliable ones in a test quarantine, then the team won’t lose its faith in continuous integration and it can live and support the team. Let’s see how to set up a test quarantine. Read more »

VN:F [1.9.17_1161]
Rating: 10.0/10 (2 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.17_1161]
Rating: 0.0/10 (0 votes cast)

When Expand and Collapse Got Beaten

Posted by on 2011/09/14 No comments

Today’s post is an instructive story about mixing various good patterns and ideas. They are very useful separately, but when one uses them together, they may lead to problems which nobody wants to deal with at all.

We found several different defects in a certain feature, and in order to reduce handover costs I collapsed them together to make an “umbrella defect” (defect1+defect2+…defectN) and put it into our Queue. When my colleague started to work on it, I was quite happy with the result: less handover costs less context switching and more focus on a faulty feature. It was really nice until our deployment day came. Or Kanban board and version tree looked like this:

The mentioned umbrella defect appears as ‘UD‘ on the Kanban board, and it covers ‘UD1.1‘ and ‘UD1.2‘. Based on our Kanban board, there is no impediment to the deployment, but right before the deployment we realized that not everything we wanted to deploy had been tested since we were using one-track. One-track means that we don’t have branches, labels or tags, we just have the trunk where we have our latest version. One-track is an excellent thing, but it seems that it doesn’t work well with collapsing.

Read more »

VN:F [1.9.17_1161]
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.17_1161]
Rating: 8.5/10 (2 votes cast)