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 &quo

 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  totally abstract  and