Level Up Coding

When people who have visited Lourdes claim to have been cured by its holy waters, there are several possible explanations: 1. They were going to get better anyway, and their pilgrimage just happened to coincide 2. The fact that they believed so strongly in the healing power of the water had some physical effect on them, acting like a placebo, which helped them to recover 3. God made them better Personally, my money's on 1. or 2. as the more likely explanations. It certainly happens that people recover without treatment, or with a fake treatment designed to make them think they're going to get better - especially if they really, truly believe that the treatment will work. And it also just so happens that software development organisations improve without external help. At best, when consultants like me come in, we act as placebos, helping you to really, truly believe that you're going to get better. I find the idea that organisations improve because  consul...

 Just a quick post to put an idea out there. Yes. Another half-baked idea... But bear with me for a minute. So, fans of OO design quality metrics (and that's all six of us I'm talking to) will be familiar with a metric that indicates whether our inter-package dependencies are tending to go towards more abstract packages. It's called distance from the main sequence. The design principle it's based on is the  Stable Abstractions  principles, which states clearly that packages that are more depended upon should be more open to extension and less open to modification - i.e., more abstract. It occurs to me that the same goes at the class level. But we tend to just think of abstractness of classes as being two-valued -  abstract  or  not abstract . But is an abstract class with some methods implemented and others left purely virtual as abstract as an interface with no implementation at all? I don't think so. I think the interface is  to...

 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, ...