Level Up Coding

 I keep hearing debates flaring up around and about the countryside on the topic of whether or not Agile values and practices scale up. Well, I don't get it. I really don't. With my limited understanding of what it means to be "Agile" - iterative & adaptive (i.e., evolutionary) problem solving, self-organising teams, emergent designs and so on - it rather strikes me that if what you're doing doesn't scale up then it probably  isn't  Agile. What makes me think that? Well, wherever I see these strategies being applied successfully in nature, they are being applied at the macro level. These are strategies for solving very complex problems, and I'm afraid I just don't buy into the notion that 20 Scrum teams is a fundamentally different problem - on a fundamentally different scale - to 1 Scrum team. They're both in the same very rough complexity ballpark. Frankly, I think it's the  lack of Agile-ness  (or should that be ...

 It's shocking, isn't it? I mean, the nerve of some people! I just finished a technical interview with a self-proclaimed "build engineer" - apparantly expert in .NET, Ant/NAnt, CruiseControl, continuous integration and all that jazz. His CV claims he's been doing it since Year Dot, so you'd think he'd be pretty good at it by now, wouldn't you? So I hand him my laptop and ask him to write a NAnt script to compile a .NET project and run a suite of NUnit tests. That's kind of like the "Hello, World!" of build automation. I stay to pair with him, but, as it turns out, for nought. He didn't even try. Didn't know where to start. And that's after I pointed him to the dozens of similar Nant scripts sitting on my laptop that he could have copied from. Shocking! So I move on to the second part of the technical interview and tell him that I have a couple of C# development tasks I'd like him to try - just basic st...

 One question that really bugs me is: what is the average effectiveness of unit tests? Why do I want to know this? Well, because people are always asking me, that's why. I show them Test-driven Development as it is written (so mote it be), and demonstrate 100% code coverage, 100% path coverage, 100% constraint coverage and then use mutation testing to demonstrate just how really very bloody good my unit tests are. (And they are very bloody good indeed. Oh yes.) And it's usually around this point that someone in the audience puts their hand up and innocently asks: "So how far do people go on average projects?" (Because that's the level of ambition I'm up against, godammit! 90% of developers just want to not be worse than average.) And the truth is, I have no idea what the average level of unit test effectiveness is. None whatsoever. Diddly. You see, I'm a bit like the Queen. She thinks that the world smells like wet paint, because w...

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