I was at XP day last week in London. I thought i’d log my notes here in no particular order.
- Think about Flow rather than batching to reduce risk and deliver value more quickly, if doing this highlights transactionally expensive procedures (e.g. release) then look to reduce that cost by eliminating waste or automating
- Have checklist/ritual detailed about swimlanes describing entry criteria
- Pull board items through the swimlanes rather than pushing them and have limits on the number of items in each swimlane. This highlights bottlenecks early and makes the team swarm around bottlenecks rather than generating more backlog
- Karl Scotland showed this concrete example of how multi-tasking causes project delays due to context switching
One of the systems I work on contains several distributed processes communicating via Active MQ. Integration testing these components has proved unreliable and complex so I attended Testing asynchronous behaviour and got the following inspiration.
- Testing asynchronous apps makes your unit test code messy and complex waiting for callbacks, state changes, etc. Instead wrap the asynchronous sections in an API to simplify your unit tests.
- Abstract the messaging interface, implemented a threaded messaging solution and then test the distributed components in separate threads but in the same process space.
An interesting open space titled Why aren’t they typing more. This introduced the Japanese word Mu roughly translated as ‘To un-ask a question’. e.g. The question ‘Why aren’t they typing more’ (often asked when managers see developers pairing) is such a ridiculous question that the person asking needs to un-ask that question.
Real Options is a decision-making process for managing uncertainty and risk. It’s a simple and powerful approach that helps us make better informed decisions, as individuals and in groups, by understanding and responding to the psychological effects uncertainty has on our behaviour.
On the day I didn’t realise just how much we do this in everyday life. I’ve written more on this in a separate post.
I participated in a coding DoJo called ‘Dirty Jobs’ in which 15 of us paired to add a simple new feature to a (deliberately) complex, messy and untested piece of Java. This was interesting to see how many problems we could identify in the code, and how different people felt we should address the problem, ranging from ‘refactor to make testing possible’ to the diametrically opposed ‘test what we have then refactor’.
An enjoyable and worthwhile two days.