I recently decided I want to get better at playing the piano. 30+ years ago, I had some lessons playing the electronic organ, but though I’ve played a few things since on a piano I’ve never taken it seriously enough to do some deliberate practice. That means I’ve played a few songs from sheet music, but haltingly and never practiced enough to get the difficult parts right and the whole song memorised.

This is a rambling-about-random-thoughts post. It goes a little out there. Have fun!

This post was triggered by the Lean Code talk at #xp2017, by Desmond Rawls (@okokillgo)

Using Lean Startup principles to improve code quality. Nick was using the normal code quality metrics for this. That is good, but: not all that actionable, and not showing directly what (I think, and he also seemed to say) the goal is: code that can easily be changed to adapt to business demands.

The ancient and respected team of Science Ninja is amazing. For centuries (or so it seems) they’ve protected the temple of Llabdum. The temple is old, with many places showing signs of previous attacks, or simply crumbling rock and weapons still in the skeletal hands of fallen enemies. Or maybe, you know, just lego bricks left lying about by younger Ninja-to-be.

People always marvel at the antics of the Ninja. As they practice moving between different parts of the temple, they put on blindfolds and go from one place on the defences to the other. Some places, they manage to walk in the exact rhythm needed to avoid the lego bricks on the floor, with running strides of the exact needed length, and that final jump at the end of the corridor. Some of the more experienced Ninja know how to cross the ancient garden, with its many treacherous walls, pits filled with blades, and snap-wires intended to trap unsuspecting intruders. They jump, flip, pirouette, land on their fingertips before doing a perfectly timed series of flip-flops through a line of moving stone wheels, ending up on the southern wall ready to defend the temple.

It’s funny, isn’t it? Everybody is still talking about ‘scaling agile’. A whole industry has been created on the premise that large companies need process structures to help them manage pushing very large projects through huge sets of development teams.

Luckily, the DevOps movement (and the continuous delivery movement, I’m not sure they’re really separate) happened early into that process, so in most of these large scale processes there’s at the very least lip service to the idea that quality needs to be high, and delivery needs to be automated, even if they don’t aim for continuous.

Everyone seems to want to get on the Continuous Delivery train. Rightfully so, I think. For most, though, it’s not an easy ride. From my work with client and conversations with other coaches there’s a few common barriers to adoption.

In the end, the goal should be to be able to react faster to the market. And, to be honest, to finally be in actual control. But in business terms, it’s about cycle times. That’s what allows you to not just react quickly to market circumstances, but to actively probe markets and test product ideas.

For the last five or six years, I’ve been using coding exercises during job interviews. After talking a little with a candidate I open my laptop, call up an editor, and we sit together to do some coding.

My favourite exercise for this is a refactoring kata that I came up with. I’ve always found it more interesting how people deal with bad code they encounter than any small amount of code that can be written in this kind of short period.