Hiccupps

I've said many times on here that writing for me is a kind of internal dialogue: compose a position, propose it in writing, challenge it in thought, and repeat. I get enormous value from this approach, and have done for a long time. But in two discussions last week ( Lean Coffee and a testing workshop with one of the other teams at Linguamatics) I found additional nuances that I hadn't considered previously. First: in some sense, the approach I take is like pairing with myself . Externalising my ideas sets up, for me, the opportunity to take an alternative perspective that doesn't exist to the same extent when I'm only working in my head. It's often about the way I'm thinking as much as the content of my thoughts, and I speculate that this is a good grounding for being criticised by others when we're working together. Second: writing and re-reading makes my position clear to me, and forces me to work out a way in which I can put it across. Since I...

This month's  Lean Coffee was hosted by Redgate . Here's some brief, aggregated comments and questions  on topics covered by the group I was in. What benefit would pair testing give me? I want to get my team away from scripted test cases and I think that pairing could help. What do testers get out of it? How does it improve the product? It encourages a different approach. It lets your mind run free. It can bring your team closer together. It can increase the skills across the test group. It can spread knowledge between teams. You could use the cases as jumping-off points. I am currently pairing with a senior tester on two approaches at the same time: functional and performance. For pairing to work well, you need to know each other, to have a relationship. There are different pairing approaches . How long should you pair for? We turned three hour solo sessions into 40 minute pair sessions. You can learn a lot, e.g. new perspectives, short-cuts, tips. Wh...

After I blathered on and on about how much I'd enjoyed Ron Jeffries' Extreme Programming Adventures in C#  the Dev Manager  offered to lend me his copy of  Extreme Programming Explained  by Kent Beck. Some background from  Wikipedia : Extreme programming was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project. Beck became the C3 project leader in March 1996 and began to refine the development methodology used in the project and wrote a book on the methodology (in October 1999, Extreme Programming Explained was published). So I took the book (it's the first edition) and I enjoyed it too, but differently. I might say that if Adventures is a road trip, Explained is a road atlas . One of the things I liked about Explained (that it shares with Adventures) is the suggestion that only you can really decide whether XP can work in your context, and how. Also that Beck is prepared to offer you suggestions ...

Houghton Mill is an 18th-century water mill, full of impressive machinery and, last weekend, actually grinding flour by the power of the river Great Ouse. Although I am not knowledgeable about these kinds of buildings or this technology I found myself spellbound by a small, but crucial, component in the milling process, the slipper . The slipper is a kind of hopper  that feeds grain into the millstones for grinding, Here's a short film I took of it in operation when I was there with some friends and our kids: It has a system of its own, and also it is intimately connected to other systems. It has inputs: a gravity feed brings grain into the top of the slipper; energy is supplied by the vertical axle which is in turn driven indirectly from the water wheel. It has outputs: grain is dropped into the centre of the millstones immediately below it. It is self-regulating: as the flow of the river varies, the speed of the wheel varies, the rotation of the axle varies, ...

"I'll start, however, by assuming it's going to work. No need to borrow trouble from the future."  That's Ron Jeffries, in Extreme Programming Adventures in C# . I'll start, however, by assuming it's going to work. No need for me to know much about eXtreme Programming (XP) and less about C#. And that's me. Interestingly, in some very real sense, this book didn't help me to overcome either of those lacks. And yet I still strongly recommend it. Why? For one thing, because of quotes like the one at the top. It's essentially the thesis of the book, repeated in various forms from just about the first words in the Introduction ... I start with a very simple design idea and implement features in a customer-driven order, using refactoring to keep the design just barely sufficient to the moment. ... to the last words in the final chapter, Project Retrospective: Does incremental development work? This, of course, is the big questi...