This evening I gave a talk at the Neo4j User Group about zeebox’s use of neo4j and how graphs allow us to provide a better user experience. It was good fun and a great evening, many thanks to the Neo guys for the invitation.

The talk was recorded by Skillsmatter

This evening was a challenge, I gave two talks to the London Cassandra group. I was only intending to give one talk, however the second speaker, also from zeebox was ill so I needed to stand in, thankfully it went down pretty well.

The first talk was around data architecture and the role of Cassandra at zeebox. The second was around zeebox’s experience with Cassandra and using it from Scala including the library our guys had written to make working with Cassandra type safe. I hope to see blog posts on both subjects on the zeebox engineering blog at some point.

Earlier this year I did a talk at London QCon on the “Agile in Actuality” track. Katherine Kirk invited me (at fairly late notice) to do a real world talk, something from someone actually working in the thick of it, not from the perspective of an interloper. The talk was hard to do, not helped by being quite ill in the preceding couple of weeks, but it was a great learning experience for me.

You can find the recording on InfoQ here.

I sat down and did a personal retrospective, tried to assess what went well, what didn’t go so well and what would I try and do differently for my next talk.

How did it emotionally make me feel:

• Elated, drained and relieved.

What went well:

• Nerves - whilst I was pretty nervous, at no point did I feel overcome by nerves.
• Subject matter - the content of the talk was pretty well received, most of the audience seemed to be able to relate to what I was saying.
• Flow - I felt the talk flowed pretty well, timing was reasonable, and I never felt rushed.

What didn’t go so well:

• Lacking a single takeway point - there wasn’t one thing that stood out as the one thing I wanted people to remember.
• Being misquoted - I overheard a couple of poeple misquoting or taking a selective comment out of context a couple of times later in the day - that was probably the hardest thing to accept.
• Being prepared for questions - whilst I had done the talk a couple of times previously, I didn’t take as many questions in those, and I wasn’t really prepared for some of the questions I was asked.

What I would do differently next time:

• More preparation, I don’t know how many hours I put into preparing the talk, it was a lot - but I think it could have been better done, I should have done more presentations of the talk than I did.
• Different format. I did essentially three stories from my personal experience, I think it was too much as context got lost and I should have perhaps just focused on one of those stories.

In March I will be speaking at QCon London on the ‘Agile in Actuality’ Track, it should be an interesting experience being my first big conference talk. Hopefully I will manage to convey the message clearly enough, it will certainly be a challenge.

Recently I did a presentation to the engineering group of my company about my team’s work. It has now been in production for twelve months and was a good time to talk about the challenges we had faced so far, what we had learnt and then try to apply. A lot of it however was about how we turned a difficult situation around, one all too common in software, firefighting.

The single biggest point that I attempted to get across in my talk was the power of incremental change.

When there are a thousand things that are wrong, it is often tempting to try and change everything at once, to leap from the current bad situation to a planned (an imagined) better one. The problem with this is that the large step change, like a big code rewrite, is unlikely to go well. (A big code rewrite is often an attempt to do just this).

Why is this?

It is all too easy to underestimate the inertia of a given situation. Inertia is the measure of a body’s resistance to changes in velocity. Whenever you want to change a situation, you are in effect changing its velocity, so you need to apply force (expend energy) to move the ‘mass’.

Now the problem is when changing a situation the components that make up the ‘mass’ are not tangible things, so they are underestimated or overlooked completely.

So what is this ‘mass’?

• The current state of everything the team is responsibile for or has a stake in. That could be operational incidents, bugs, technical debt, code quality, size of backlog and so forth.
• The current state of the team and those within the sphere of influence. That is things like attitude, engagement, fear, experience, knowledge and motivation.
• The framework in which the team works. That could be SCRUM, Kanban, waterfall or so on.

What does all of this have to do with step changes?

In order to make a change, we need to apply energy to alter the interia. So to do this in a big step, it will require the application of a lot of energy.

However the problem is that is the ‘mass’ of the situation is in reality unknown, so the application of force will consequently have an unknown result. The end result will most likely be in significant error compared to the desired endpoint. You are throwing a lot of energy against this ‘mass’ in order to make a change, and when you don’t get the change that you expect you grow frustrated, disheartened, disappointed and angry. This will further worsen the situation, the very thing you were trying to address.

So, how do you make a change from being in state A to state B without significant error and the resulting frustration?

There are so many dimensions to the problem, many more than mentioned here, that it makes the probablility of error in steps of any significant size extremely high. The only way to reduce the magnitude of this error is make the steps smaller. By making smaller steps and then measuring the result you are then able to feed that back into the next small step. Small errors are easier to correct than big ones.

One of the challenges of this that it can make people impatient, nothing seems to be happening and they want to leap on ahead. However its deceptive, small changes acumulate like compound interest, and sooner than you think they make a very real difference.

There is a lot more I could say on this topic regarding measurement, developing options and process - however that would make the step bigger, detract from what I am trying to achieve and introduce error.

Small incremental steps will get you there faster than you think and closer to where you want to be.