Glen Ford

usersource.net

Latest Blog Posts

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.

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.

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).

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.