Distributed Thinking

I'm beginning to wind down for the xmas break - just the Student Systems Board tomorrow, a meeting of the Applications Architecture Governance Group, a review of the first phase of development for the new university web site, then a xmas curry with the web site team on Friday, and that will be me off for a couple of weeks.  But before I finish, I want to record some thoughts about our IT Futures conference for 2013 , which was held last week. We started planning this in January, when we were thinking about ideas for a theme and potential speakers.  I had the idea of inviting a science-fiction writer to give an outsider's view of what higher education might look like in the future.  This was tossed around a bit and Jen Ross suggested Cory Doctorow.  Meanwhile, the theme of "disruption" rose to the surface.  We put the two together and a potential agenda began to take shape. The next step was to add a less technical and more people-oriented take on "disruption&

On Wednesday evening, I had an “Aha!” moment when listening to Steve Freeman talk about Test-Driven Development: That’s not what we meant at the local branch of the BCS.   Apparently there has been a bit of backlash against TDD recently, with people complaining that their test suites are so big and fragile that they take more effort to maintain than the actual code does. Steve was explaining his approach to writing tests and how to avoid these pitfalls. As part of his presentation, he advocated that tests should be written for interfaces not implementations, and in fact for protocols rather than interfaces.  He contrasted an example of good practice, using a combination of externally visible methods to test behaviour, with a poor example that used a backdoor to twiddle internal state.  He remarked that it was only when he started to write these sort of tests that he finally understood the oft-repeated mantra that logical models should be separated from the implementation. This was