Sunday, April 12, 2015

Identifying contributions: on doing vs helping

Over the last few days, I've been thinking about a tweet exchange with Michael Bolton. It seems we feel very differently about the need to separate who does a thing in development (programmer) and who helps do it (tester). And I realize my perception of this has changed a lot with working in agile projects.
In agile projects, it's typical to work in pairs or groups. In a group, we don't discuss who is doing  and who is helping as both contribute. We don't care. I don't care.

I find that it suits my personality and style of doing things in general. I go around meeting people and hear things others would be interested in but don't manage to get forward with in organising. I take the idea, pass it around to a few other people to seek the energy and in a few weeks, we're having a meetup to share ideas and experiences on the topic. Without the person who triggered me, nothing would happen. Without me, the session wouldn't happen. We both contribute to a common goal and attribution of pieces just seems irrelevant. We're in it together but the need to attribute individual contributions sits deep. I hear a lot of people telling they did nothing in these interactions, while I recognize that their contribution was the force that set things forward.

Think about it this way. Imagine you're baking a cake. You'll need sugar, eggs, flour and a bit of vanilla for the flavor. With your recipe, the cake is really good. Which of the ingredients contributes to the goodness? Can you leave out the sugar? Can you drop vanilla, since that's the smallest portion in the ingredients? All of the ingredients are actually necessary, and you can't really tell which one of them individually contributes what to the goodness of the cake. The right answer to me seems to be: I don't care. I care that the cake is good.

In doing something in team together, I don't care whose contribution it is. Without the help (if that is is what you want to see a tester contributing) the end result is different - and I believe inferior. Identifying individual contributions and focusing on roles rather than skills we bring into the collaboration seems like a dead end to me.

I was given advice on getting all wind up about this with an unattributed proverb:
Don't get into argument with an idiot. He'll drag you down to his level and beat you with his experience.

The advice kind of sums up what I still haven't learned: arguing over semantics is a waste of time. Arguing in general is a waste of time. I'm reading now Deborah Tannen's book The Argument Culture: Moving from Debate to Dialogue / Stopping America's War of Words, and that text resonates big time with what is going on in the testing community. But that is a topic for another post.

Just for the record: I admire Michael and don't think he is an idiot, quite contrary. I should learn to pick my battles, and on this one we're just fundamentally coming from a different place. I recognize that and continue admiring him and his contribution to my self-understanding as well as testing profession in general.

No comments:

Post a Comment