They don't like it up 'em!

No point moaning, José, Chelski were crap and lucky to get the result they did. I’m not suggesting that going to London with a one-goal advantage against Chelsea is going to be easy for Barça, but I’m not expecting them to fail, either. Força!

Knobs 'n' stuff

I’m looking around for music control surfaces, leaning towards Behringer’s B-Controls, especially the flying-faders-equipped BCF2000. But I have to wonder: are they going to come out with a daddy unit for this series? Like a box that contains the faders version *and* the rotary one? Or 2 of each? And if not, why not? In any case, could I just buy the bits and stick ’em together in a bigger case? Watch this space…

Refactoring, unit testing, all that…

I’ve always been more of a procedural kind of a programmer. After Spectrum BASIC and the inevitable QBASIC, it was on to C. This was all hobby and/or academic stuff. Professionally I used Perl far more than anything else, and always in an “if it works, f**k it!” type of methodology (thanks, Mr Hume, for the turn of phrase…) This was because more of what we were doing involved either single-shot web pages, text processing, system admin, and other short-lived “make it work now” tasks. By the time you’d be coming to make changes to the code and need to be able to understand it, it would be time to rip it out completely and build a completely new website. So it made perfect sense.

Working with object-orientated PHP4 isn’t exactly the most fun you can have with your clothes on, but it has got me into some eXtreme Programming methods. I can’t follow through on all the methods – it’s hard to do pair-programming when you live in Tarragona, and I never even *see* most clients, as few are in the same country as me – but starting with unit testing and leaning heavily on refactoring are techniques that can work when pulled apart from the whole XP ride [see this for an alternative view].

The idea of “proving it with code” – starting to code before you know fully what direction you’re going to go in – suits me down to the ground. That’s how I’ve *always* worked anyway. There come very quick realisations about the requirements as soon as you start hacking. *Then* you can make some notes about them.

I’m definitely in two minds about pair-programming (regardless of the geographical practicalities). Some people are just *meant* to work alone. Many good programmers are like that – are they supposed to be either forced into a different methodology or discarded under XP? Sometimes it just clicks between two programmers and they can work together, but I doubt just *any* two minds could be dragged together like that. Personally, my best MO is to get together regularly with others on the project then disappear while I code. It’s like driving – if you look down at the gear-stick, it’s harder to change gears than if you just change them. (Uh-oh, in danger of sounding like Obi-Wan now: “use the force – reach out with your feelings”!) But sometimes coding in a natural, almost unthinking way can be the way to really great, elegant ideas. As Matt Stephens says: “Programming done properly is meditation – your mind transcends to some other place, of pure thought, with a thousand variables being juggled effortlessly.” It might be possible to do that alongside someone else, but it would have to be an inter-personal synergy like Lennon/McCartney! Personally, I think I’d rather scrum then go off and use the force, Luke.