The team leader role

A couple of weeks ago I had the opportunity to participate on a workshop held by Jurgen Appelo (XP2011, Madrid). I like these kinds of “shows” (and by show I mean workshop); it’s not about the talk only, but the audience’s involvement. It’s always exciting to learn something through funny events and games.

This was the first time ever I played this cool game, called delegation poker. In short, there’s given a group of 4-6 people; they are taking turns in telling stories. At the end of the story, each and every player has to decide upon one of the seven levels of delegation they think fits the best (for a more detailed description, read the original document. Really, you should try it once, it’s fun!).

What actually amazed me in this game, is people’s different view on the very same concept. I was part of such a group, and here are the stories and delegation levels we had (let’s denote different people by letters, names don’t matter after all). You’ll see that all the stories are targeted at the team leader’s point of view.

Story #1

There is given a newly set up team. They are quite new to TDD, XP and generally, to all agile techniques. From a team leader’s point of view, what level of delegation should be used in order to facilitate pair programming?
A: Level 7, ‘team members should decide whether they want to pair up or not. As a team leader I don’t care about pair programming as long as they deliver quality’
B: Level 6, ‘let the team decide about this, but I would like to have some feedback at the end’
C: Level 4, ‘team leader should be considered as part of the team. As long as they are taking part in coding, they should be treated as any other team member’

Story #2

Let’s say you are a team leader. You lead a cross functional team of experienced people. You have the possibility to choose what methodology you want to follow: Scrum or Kanban.What’s the delegation level?
A: Level 6, ‘I was wondering whether this is a six or a seven. The only reason I picked six is I really would like to have some feedback on this. This is an important decision, so I would like to be involved in it.’
B: Level 2, ‘I would like to make sure we follow the methodology I consider best. So I can protect my team better, and can shield them from the pressure from upside.’
C: Level 5, ‘I would tell some  pros and cons of both. Then I would have the team decide which one would they rather follow. I want to make sure we apply the techniques the whole team believes in.’

Story #3

Again, we have a team of experienced developers. What delegation level would go best when deciding about punishments for the ones being late to standup meetings.
Guess what, we all went with a five to this question. It was the first and only story when we all agreed upon the very same delegation level. We all thought the team leader should have some influence on this one -like insisting on having punishments- but not in a command and control style.

And that was the point when we run out of time. There was no more time for situations and/or discussions (unfortunately, I would say). I don’t even know what would be the definition of a team leader based on the stories above. Is a team leader a proxy who makes the management pressure vanish (#2)? Are they the ones who tell people how to do their job, based on best practices (#2)?  Or persons who feel they really are part of the team when it comes to important decisions (#1)?

As I see there are two “schools of thought” here fighting; the first one considers the team leader rather a manager, the other thinks team leaders are rather team members (who “manage” their teams seamlessly). The question is, which perspective is more useful from the team’s point of view? (provided that, there really are team members who are dependent on their team leader. These are the persons who keep asking “what task should I do next?”)

Anyway, no conclusions drawn; I guess one cannot clearly state which one is best. It was, after all, a very good experience, and a very good lesson on different people’s different visions. You are welcome to share your thoughts.

TDD avoidance – Top 10 reasons

I’m sad to see we somehow got way too far from agile coding, best practices and quality. It seems that TDD has its life cycle curve inside our organization (who knows, maybe we can generalize further). At the beginning everyone is excited about the new way of working. They seem to be adapting things, trying out TDD, mocking and the other technologies. After a while, however, people feel test driving feature development is a waste of time. So they stop writing test cases and get back to their old way of working. At the end, the organization is left with very few people committed to TDD.

And this is the strange part. Quality drops, because nobody cares about it, but when it gets noticeable everybody cries around. And that is the point when people start shouting louder: “This code is pretty much a mess, we’d rather rewrite the whole thing”. A friend of mine told me the other day “you cannot expect people to be writing test cases; they lack dedication”. (By the way, in this case I wouldn’t expect them to be complaining about quality… but anyway) And I guess this is the point here. Lack of dedication.

I tried to figure it out, so I started walking around in the landscape and ask people why they don’t write test cases. Here is my top ten answers I collected. Are you ready? Ok, here we go:

  1. I am so smart I can implement this without test driving it
  2. I don’t know how to write tests
  3. This is a really small change, no need for tests
  4. This cannot break anything
  5. I’m in a rush, no time for TDD
  6. I wanted to write tests, but I didn’t 🙂
  7. It’d be too hard to test this mess
  8. TDD’s not a silver bullet. With or without it, doesn’t matter
  9. I’m prototyping
  10. I’ll do the real work, then you can play around with your tests

The sad thing is that I didn’t make up any of these…

I’d like to emphasis this one: “I’m prototyping”. It seems to me that as soon as people get to know about prototyping they get an excuse not to do TDD. Tricky prototyping this is after all. People write a bunch of code, call it a prototype and -guess what- check it in! Ok, first they cross their fingers and say “I hope this works”. So we fall back to Hope Driven Development (thanks for the term, Marcell).

And finally, number ten. I really heard someone say that when I proposed we do test driven development. Some people don’t even consider writing tests real work.

Sadly enough, people who already had the OMG moment seem to forget about tests (I call OMG moment when someone discovers how useful TDD is. Usually it happens when they miss a bug, but their tests catch it for them). One idea we could come up with is a regular TDD group, with the committed ones (this would involve regular meet-ups where we could teach each other tricks, techniques and other stuff. Perhaps after a while everyone will be confident about their skills, so we get several TDD mentors). Maybe we can place them in different  teams so they can “infect” others with TDD (they can insist writing quality code at pairwork sessions). Maybe it helps, maybe not. Any comments welcome.

Test code – not second-rank citizen

Some time ago I had the opportunity to browse some test code written as exercise. The code was actually written by a person quite into TDD, that’s why I got a bit surprised. The test code looked like it was written very long ago, and got abandoned shortly after its creation.

The exercise at some point required the solver to find negative numbers in a matrix (let’s just skip the other things not relevant for this post).  The first test method written against a method was called there_is_no_negative_number(). After that all the test cases followed the very same naming convention.

I, personally don’t like this naming style for several reasons:

  1. Test code should not differ from production code in format, coding conventions, naming conventions etc. I’ve never seen anyone naming methods in production – Java using underscores (and neither did the kata solver). That is the old C format. Java has its own coding standard, as Sun have clearly stated. Using the C style in tests and Java style in production doesn’t have any added value, but it’s rather harmful. It makes the code hard to read and it looks like two different people have written it. I am pretty sure no one would call a method parse_int() or value_of() in production code. Test code shouldn’t be any different.
  2. After reading the test method’s name one doesn’t get what the hell is going on in there. I mean we see there are no negative numbers, but where? In what context? Is it forbidden to have negatives or just a simple test case? What method is under test? What happens if there are no negative numbers? What if there are? This naming convention is rather rising questions than answering them. When I first met TDD, my mentor told me: simply by reading  a test’s name I should be able to tell what method is tested, for what parameters and what the return value will be. Then I learned about the “should-centric” test case naming convention. The test case above should be rather called -in this context- containsNegativeNumbersShouldReturnFalseIfTheInputContainsNoNegativeNumber. This name is kind of long, but much intuitive. As you can see all the questions above are answered by the test name itself. Imagine something going wrong in a huge code base. Which test would you rather see fail? In the first case you have to read all the test method body to figure out what the test is about. In the second case you just read the method name and get the context immediately. I’d definitely go with the long name.

Another thing I don’t really consider helpful is relaxing problem constraints in one direction only. In this concrete case the problem was relaxed horizontally. This means that the solver was trying to get the exercise done by first considering test cases for arrays only. Obviously arrays do not have all the properties matrices do, so these test cases are not taking us any further. However, relaxing constraints in both directions can be a good idea. In the case above (where we were given a matrix of four by four) it would have been nice to start with matrices of 1 by 1. 2 times 2 afterwards and so on.

In short, tests should be treated like production code, while problem dimensions should be relaxed symmetrically.

Code Kata Nr. 6

This week’s code kata is a little bit more advanced. This time one has to use several different techniques in order to solve it. I admit, the exercise itself is not my idea (found it on the net), however I like it very much, since it’s about soccer.

So, here it goes; There are given several teams and their strenght expressed as integer values (for a list of country – strength point values see this link: These values can be used to predict the outcome of a game between two teams. The formula for that is the following:  (In order to keep it simple, we assume that the team with the higher probability to win, wins the game). Of course teams’ strength are not constant. They have to be changed as teams play games. Winners’ strength increases while losers’ strength decreases.

Now, as we know which team wins and which loses, we have to update their strength points. The formula for that is the following:  where:

  • I: importance of the game. This can be a constant; 60 is its default value.
  • GD: goal difference. This is a random number between 1-6.
  • R: result. Its value is 1 for a win, 0 for a loss.
  • Win(expected): given by the formula above.

What the kata requests you to do is to predict the winner of a game, increase their strenght and decrease losers’ strength. If this is too easy for you, then select several teams, and predict the winner of a whole tournament.

This kata is nice for a number of reasons;

  1. In order to solve it in TDD, it needs the random number either to be injected (dependency injection rulez!) or faked.
  2. Finally a kata, which requires you to have several classes.
  3. It familiarizes its solver with JUnit’s assert for floating point numbers (remember two floating point numbers cannot be considered truly equal; When testing such numbers for equality, you need to pass in a third argument to the assert. That is a delta walue, which tells the maximum difference between the numbers at which they are considered equal.)

Solve it, have fun, and if you really want to play it on the hard level, have a time limit of 30 minutes (OK, up to one hour).

Test overkills

I’ve seen kind of many times lately the following “pattern”;
Suppose we have a simple class, something like this:

public class Class1 {

    private String name;
    public String getName() {

And a wrapper class:

public class Class2 {

    private Class1 class1;

    public Class2(Class1 class1) {
        this.class1 = class1;

    public String getName() {
        return class1.getName();


And now a test case for the latter:

public class TestClass {

    	JUnit4Mockery context = new JUnit4Mockery() {

        final Class1 class1 = context.mock(Class1.class);

        public void shouldReturnTheValueNameForGetName() {
            Class2 class2 = new Class2(class1);

            context.checking(new Expectations() {
            Assert.assertEquals("name", class2.getName());

I mean why? Why would anyone put that value into an assert? It’s obvious that this assert will never fail. We told the mocking framework to return the value ‘name’ when the method getName() is called. Of course it returns the value we told it to return. So the assert is completely unnecessary there.

Of course, no one writes tests for getters… Don’t get me wrong, I’m not complaining about writing tests for getters. But still, people keep writing test cases that test values returned by the mocking framework. These tests can, at most, test the framework itself.

Anyway, values returned by expectations should never be tested. It’s like Assert.assertTrue(true); Tests that can’t fail are not testing anything. Tests that not test anything should be removed from test suites.