Level Up Coding

 The fact that I'm flying to the Canary Islands for my winter holiday is not the point of the holiday. I don't love to fly, and would prefer to just sort of mysteriously "arrive" at my destination, ideally with a nice cold glass of Chardonnay in my hand. Unfortunately, there is the small matter of physical distance to be overcome. So I have to sit on a plane for four hours while about a thousand miles of fresh air whizzes by me. But I consider myself a holiday maker, not a passenger. The flight is not the point of the holiday. It is a means to an end. And someone who does test-driven development is not a tester. The tests are not the point. They are a means to an end. The end of TDD is well-designed, working code. In TDD, we use tests to specify what code we should write. The fact that we can run these executable specifications and get immediate feedback that our code works is a bonus, and a big one, but it is not the purpose of TDD. It is a very usef...

 One of the thornier facets of being a "design authority" is that you are invariably called upon to make a professional assessment of other peoples' designs. (In a process, often compared to pulling fingernails, known as a "design review"). A team of developers might get a little precious about someone like me asking awkward questions about the design of their code, but that's a walk in the park compared to reviewing code that's been architected (by an architect, no less…) Some architects will defend their design decisions to the death, and quite often will use every intellectual and political weapon in their arsenal to repel hostile agressors like myself - godless heathens who have the nerve to saunter nonchalontly into their empires and say things like "should the data access code be in the same classes as the business logic?" and "shouldn't that class that everything else depends on be a bit more abstract?" and other g...

 If we didn't have schedules, would we somehow feel the need to fill them up with "stuff". And I can't help noticing that the busier my schedule says I am, the less I seem to achieve. I think this might be because much - indeed, most - of what I achieve happens unexpectedly. That's the thing about innovation, you never quite know when it's going to strike. But you have to have the free time available to exploit innovations when they pop up. Organisations that live and breathe their schedules should maybe stop and ask themselves if the goal is to keep people so busy that they're distracted from the noise around them that many great ideas will emerge from. Latency is the price of agility .

 What with all the to-ing and fro-ing and huffing and puffing and screaming and shouting (and biting and gouging) that goes on in most business IT organisations, it can be all-too-easy to forget that we are ultimately all working on different parts of the same system. By arbitrarily breaking software into chunks - projects, applications, components, services - and then organising ourselves around those chunks, we can end up losing sight of the bigger picture. And that can lead to situations where the left hand doesn't know what the right hand is doing. Which can, in turn, lead to duplication, disarray and conflicting goals. This can often be a symptom of a disjointed enterprise, where the silo mentality prevails from department to department and business function to business function. It's no wonder, in those situations, that the team building the order processing web application fails to collaborate and co-operate with the team working on the stock management system, ...