easy streets merging

I was thinking about merging today - what rules represent safe and easy merging - the more I can apply the easier my life would be. This is what I came up with:

• short lived branches
• merge as soon after the change as you can
• tests make you safe
• automated merge procedure
• author takes responsibility for merging if fails automated procedure
  
• code consists of small classes / methods and has good separation of concerns (thanks to Felix Leipold for that one)
  

What rules do you try to apply? What do you do when you can't?

Optimising Selenium

When a team is using selenium there are usually a few points where the team find the suite of tests is running too slow and causing pain. Below are my thoughts on how I go about solving these problems when they turn up.

Not that some of these problems aren’t technical and can apply to any software under test particularly any set of acceptance tests. For instance: I’ve applied some of these when optimizing the acceptance testing of some heavyweight C++ libraries.

I tend to take a breadth first look at the tests, take a quick scan a drill down where I think I can get most gain. I do follow my gut a little and look for patterns so your millage may vary.

Where’s the party? First I want to identify the cause - Is every test slow or can you see some big offenders to optimize to get the biggest gain for your hard work?

Selenium’s browser set up and tear down: The usual first pain point with Selenium is having tests that tear down and set up the browser for each test. Having the browser open for a full run of tests really speeds up the run, though you need to ensure that you don't have browser windows piling up on your cruise box over time. I'm thinking you want to lower the set up costs to separate threads would make it slower with that thinking?

Investment or debt: I only want to be running high value tests. Are there tests for every story and every path no matter how important; or for the critical user journeys and regression guards?

The same thing doing the same thing: The same goes for checking you are not testing the same thing again and again. Are there too many tests testing the same things? Is there value in thinning them out?

Set up: I take a look for intensive set up and repetitive tests - are they all doing the same set up? Are they splitting up a user journey into little steps doing a tonne of set up each time. Could you change the set up?

Creative testing: are there sleeps/waits inserted into the screen/clicking code to get round a problem inserted by well meaning developers? There might also be other funky test / screen code, trying to get tests passing that don't pan out well.

Error cases & external sources: are there some tests that want to see error behavior that have to deal with long waits / time-outs? Are there some components that don't render or are included from an external source, which might have slow time-out outs on firewalled boxes? (adverts or xml feeds on web apps)?

No need for sloooow? I take a look at the tests themselves - is the app slow, is that a problem? Are the tests setting the app to solve too big a problem for the level of testing you want?

Do you need that browser? (from Sam Newman). Testing in a fake browser can be significantly faster than testing with a real browser (see http://www.magpiebrain.com/blog/2007/01/28/selenium-rocks-and-you-dont-need-it/). You could also consider reducing test time by setting up and testing the view and wiring without the full supporting stack for some tests.

What do you do?

You can’t tell someone something if they aren’t ready to listen

‘You can’t tell someone something if they aren’t ready to listen’ is something I picked up from my kayak coaching training. When coaching on placid water the major concerns can be considering the position of the sun and the group, background noise and any potential distractions. But in more challenging conditions or teaching over a longer period you might need to be thinking more about the students’ state of mind, how alert they are, and their energy and stress levels.

What really got me was how well this advice applies to the office/team environment.

The more important or difficult the message you are delivering the more you need to focus on the receiver’s ability to listen. For a really critical conversation they may really need to be in a space to consider what you say without many distractions, and time before and after to think about the conversation.

For any conversation where the result counts, I try to take a second to consider the environment the conversation is taking place and where the other person is at. Sometime I get it wrong and have to back out and try again later but I try to keep it at the back of my mind.

A Moral Hazard: is your team insulated from the project risks?

Ever been frustrated when a workmate or a member of your team made such stupid choice that you had to go in there and fix things, distracting you from the stuff you should be doing? Perhaps they weren’t able to make the right choices because they didn’t know what they were risking.

There is a term in the Insurance business: Moral Hazard. Summed up it means people insulated form a risk behave differently that if they are exposed to it. For example a driver worries less about a well insured car than an under-insured one; or an extreme example: un-insured owners are less likely to torch their factory

I think this applies to software development teams also – the team’s behavior and choices differ depending on the risks they are exposed to. If you want the team to make wise choices and have good behaviors they need to feel the risks. If the push is just for delivered functionality above everything else, the team may choose to work on stories when there are bugs to be fixed as they have not exposed fully to the project risk of a buggy application’s release being delayed. You or someone might be concerned about it but unless the team understands the risk they are taking with continual story development, they don’t make the wisest choice.

I feel that its important that the team isn’t isolated from the risks associated with the project and I see that as ensuring the information about the critical aspects of the project are shared with them – as a team leader it can be tempted to shield them, but that leads frustration when they make choices that make no sense to the people with all the information.

Retrospective Word Cloud

I was asked to facilitate a retrospective focusing on the team’s recently played. Whilst it was easy to get the team to think of the timeline of the last iteration, prioritise and talk about the most important cards, i wasn't sure how to capture what they were talking about, and how to help the team to reflect on the discussion to create actions.

I chose to create a 'word cloud' - based on the tag clouds that I'd seen around (I have to admit, mostly inspired by the doctor who ones I'd seen the week before)


Listening as they discussed the cards, I wrote down important concepts mentioned and tried to summarise important points. Once done, I asked the team to look at the board and suggest actions.

NB: The colours have no special meaning -just a way to keep the phrases separate and visible and easily readable

Happiness checks

I wanted to write something pretentious about what I'm currently thinking leading a team comes down to, but that's going to have to wait as I want to pack for the gym tomorrow, I'll have to talk about something quick.
I believe that if you take some good people, keep them happy and give them interesting work, you get good output. So at the start of a retrospective I've started doing a quick Anonymous happy check.

The How to: Everyone takes a post-it and writes on how happy they are: 1 to 5. 1 being totally fraked off, and 5 suggesting they are having the time of their lives. The team fold these up and put them in the middle and then we stick them to the board. There is a quick chance for the team to make any comments and to take a second to reflect and we move on to the rest of the retrospective, but its something I take away and can help me make choices.

The Thoughts: I don't think this will work for every team as the the trust and honesty has be high (sometimes an trust/honest check would be better), but it can be a good feeling or maybe a warning indicator to the team.

Developers only count to three

I have this theory that developers can count accurately up to three. Just like my cousin could, back when he was tiny, we all count 1, 2, 3, more, and lots. That’s it, as good as it gets, so we’d better work with it.

Back a few months ago, a team I was in was having a problem with ‘exploding cards’ – they would be estimated at the IKO[1] to 6 or 7 days, but then when played, sometimes we’d burn double or more days to complete them; however small cards would be estimated pretty accurately.

As an experiment we tried taking any cards that looked like it was going to get an estimate of more than 3 (though a little pre-IKO analysis) and slice it up in to parts. Each part was estimated in the IKO and played as a separate card. It wasn’t the only thing we did to fix the problem, but we don’t get exploding cards any more and I think this went a fair way to fixing it.

Having smaller cards did have some side effects, some of which I’ll write about in a while, perhaps..

Some reasoning?

Mind Hacks (by Tom Stafford & Matt Webb) has some commentary on counting – it says we have two way of counting, yer standard counting – where you check items off one by one, and Subitizing which allows us to almost instantly spot up to 4 items; counting comes in once this quotient is reached. Now Mind Hacks suggests that this is a side effect of the visual processing part of the brain, but it seems to me to hold up for non-visual counting also.

[1] Iteration Kick Off