Software People Inspiring

Codemanship's Code Smell Of The Week - Data Classes

 

A key goal of OO design is to minimise depdencies between classes by packaging data and behaviour as close together as we can. In practice, a good rule of thumb for class design is to put fields and methods that use those fields in the same classes. Data classes are classes which just have fields and no behaviour (besides simple getters and setters), and they break this rule of thumb, creating serious dependency issues in your code.

Here, Jason Gorman demonstrates how to refactor data classes by moving the methods (or parts of methods) that use fields of dta classes into the classes that contain those fields.



Download the source code from http://bit.ly/czsOHP

For training and coaching in refactoring, TDD and OO design, visit http://www.codemanship.com

Software Is Both Art & Science. Can We Move On Now?

 

Bonjour, mes enfants.

SEMAT has gotten me thinking. Any mention of "engineering" and "science" in software development seems to polarise opinion.

Undoubtedly, there's a large section of the software development community who believe those words simply do not apply. Software development is not a science. It's an art. Or a craft. Like basket weaving. It's not engineering. No sir!

And there's an equally large section of the community who believe the exact opposite. Software development is a science. It is engineering. We can apply scientific principles to shape predictable, well-engineered end products.

Of course, they're both wrong.

Anyone who dismisses the notion of any kind of scientific basis for software development is running away from reality. Everything that exists has a scientific basis. Even American Idol. You just have to understand it. That we don't fully understand the science of software does not mean that no such science exists or that we'll never understand. I just can't help being reminded of UFOlogists who claim that "science cannot be applied to the study of UFOs". What they mean, of course, is "I've got a good thing going here selling my unscientific ideas to these schmucks, and I'd like to keep it that way, thanks".

And anyone who believes that software development can be completely tamed by science is equally deluded. There are sciences - emerging in recent decades - that teach us that there are many things in the world that, while it's possible that we can fully understand them, we will never be able to control them. Chaos is science. And software development is mostly chaos. Any vision of "software engineering", where pulling lever A causes X and pulling lever B causes Y with certainty, is the product of naivity at the macro, project scale. Life just isn't like that. Clockwork might be, but life isn't. Software development is intractably complex and unpredictable.

In the real world, biology has come up with processes that deal effectively - but not predictably - with intractably complex problems. Evolution is one such process. Evolution solves complex, multi-dimensional problems by iterating through generations of potential solutions. That is science. We can understand it. But we cannot even begin to predict what solution a process of evolution will reach, or how long it will take to reach it.

The clockwork, Newtonian paradigm of "software process enginering" is fundamentally flawed. And anyone who believes that it's possible to attain "value" deterministically is deeply mistaken. "If we pull lever A, we'll ship an extra 10,000 units". Give me a break!

Flawed, too, is any notion that this means that there's no engineering at all to be done in creating good software. I doubt anyone would claim that making rock music is "engineering" - well, anyone sane, at least. But there is science that can be applied within this process.

It's possible mathematically to predict what effect the choice of software compressor and the compression settings used will have on the amplitude of a recording across a certain frequency range. Indeed, it is helpful in getting the best-sounding mix. There is such a thing as "audio engineering" within the music production process. Granted, it's chiefly a creative process. But there is useful science we can appky within in to help tweak the results closer to perfection.

Similarly, while software design is chiefly a creative process, it can be useful to know if the code we're writing "smells" in any significant way. Some code smells can be detected just by looking at the code and using our judgement. Others are more subtle and harder to spot, but just as damaging to maintainability. Code analysis tools, as they grow more sophisticated, can complement our "eye for good design" every bit as much as audio engineering tools complement our "ear for a good mix" and music composition aids can complement our "ear for a good tune".

The trick, I believe, is to find the balance and work within the limitations of science and engineering and creative disciplines. Trying to figure out the formula for "valuable software" is every bit as futile as looking for a formula for making "hit records". And relying entirely on your eyes and ears to refine an end product has severe limitations. For millenia, we've used tools and theory to tweak and refine all manner of creative end products. We even have a word for it: "machine-tooled". The fact that you can fit a computer more powerful than all of the computers in the world were 30 years ago in your breast pocket, and it looks good, is testament to this symbiosis of science and art.

We can continue to refine and extend our scientific understanding of code and coding through research and exploration, just like any science. And new and useful tools will emerge from that understanding that will make it possible for us to produce better quality code, for sure.

And we can also continue to develop and refine the art of software development. Through reflection, practice and sharing.

There is such a thing as "software engineering", but it has limited scope, just like "audio engineering". Specifically, it's limited to things we can predict and can control, like what happens to coupling and cohesion if we move a class from one package to another.

The bigger picture of "delivering value" is a complex human endevour, and creativity, judgement and more than a sprinkling of luck is all we have that we can bring to bear in any meaningful way at this level. We may be capable of understanding, with the benefit of hindsight, why Feature X was used more than Feature Y when the software was released. But then, with hindsight, we understand quite a lot about volcanos and hurricanes, too. These are things that can only be understood with hindsight, really. We don't see them coming until they're almost upon us, and we have two choices - stay and risk everything or get out of the way and live to fight another day.

In years to come, I'll probably notice more and more a difference between "hand-rolled" software and software that has been written with some help from "software engineering" tools - the more grown-up descendants of tools like XDepend and Jester.

But I sincerely doubt I will ever be able to tell at the start of a project whether the resulting software will enjoy success or not. Sure, I'll be able to look back on projects and say "hey, y'know what we got wrong?" But far in advance, the outcome is every bit as unknowable as a hurricane, volcanic eruption or hit record. So where things like requirements and processes and "enterprise architeture" are concerned, I'll stick with arts and crafts.

Wheel-driven Reinvention

 

One aspect of software development which is at once both amusing and troubling is the ability of us young whippersnappers to completely ignore what's gone before and reinvent established wisdom in our own image - often stealing the credit.

Take testing as an example. What do we know about testing software today that we didn't know, say, thirty years ago? Sure, we have new tools and testing has to fit within new approaches to the process of writing software as a whole, but fundamentally what have we discovered in the last decade or so?

Testing behaviour still works, by necessity, much as it has always worked by necessity. We must put the system under test in some desired initial state, then we must provide some stimulus to the system to trigger the behaviour we wish to test, then we must make observations about the final state of the system or about any behaviours that should have been invoked (e.g., a remote procedure call or a database request) in response to the combination of our stimulus and the initial conditions. And this process must be repeatable and predictable, like any good scientific test.

Though the culture of testing software may have evolved, much of it for the better, and the technology may have improved (though that is questionable), and though there are undoubtedly more people testing their systems today, when it comes to the business of writing and executing tests, there's really nothing new under the sun.

The same is true of many aspects of contemporary software development. Like it or nay, iterative and incremental development is older than C. We just weren't doing it back then, in the main.

Indeed, pick any "new" aspect of development and trace it back to its roots, and we discover that most novelties are actually much older than many of us thought. Objects are an invention from the sixties. Use cases hail from the seventies. Responsibility-driven design was being practiced before Frankie told us to Relax. UML existed in a fragmentary form before the Berlin Wall came down. People were writing code to satisfy tests back when those tests were stored on magnetic tape. Indeed, some of the descriptions of programming that was done for the very first computers rings bells with those of us who practice that black art today.

Younger developers like me, though, seem to readily believe that our time around is the first time around and feel no compunction to educate ourselves about the achievements of "old-timers", preferring instead to invent things anew - with sexier names and shinier tools, admittedly.

Our desire to reinvent goes as far as redefining words that already have a well-established definition. "Agile" no longer means "nimble" , "quick" or "spry". Today it apparantly means "communication, feedback, simplicity and courage". Or "iterative and incremental". Or "evolutionary". Or "Scrum-Certified". I caught someone the other day proferring their definition of "testable", which apparantly now requires us to go through "public interfaces". This is bad news for many scientists, who must now rewrite their peer-reviewed papers to incorporate the appropriate programming language with which to express the "testability" of their theories.

If software development was physics, we might expect newcomers to work through and understand the current body of knowledge before they start adding to it. That way, at the very least, we could avoid a great deal of duplication of effort. We may also avoid the tendency of our industry to throw "old-timers" on the scrapheap just because, even though they are probably just as current in their practical ability to deliver working software, they're not "down with the kids" on all the latest street slang for concepts that have been kicking around the block for decades.

The thinking of our elders and betters is far from irrelevent and outmoded. We can still learn a thing or two from the likes of Jacobson, Knuth and Hoare, should we choose to reject fashion in favour of substance in the approach we take to our work.

Value Is Not The Opposite Of Waste: Why I Don't Buy Into Process Improvement

 

If you've been a regular visitor to my blog since 2005, first of all, thank you. You may also know that I'm not the biggest fan of mechanistic or pseudo-scientific approaches to making teams better at creating software.

Which is why I don't buy into process improvement any more. At all. In all it's guises. TQM, BPR, Six Sigma, Lean. All old wives tales and hifalutin mumbo-jumbo, in my honest opinion.

Yes, there are the success stories that devotees and evangelists routinely point to. Usually in Asia. Mostly Toyota.

But anyone can find the exception that proves the rule. I can point to 80-a-day smokers who lived to be 100. In a wider sample population, there doesn't seem to be compelling evidence that process improvement makes a positive difference in the long term.

Commoditising "value" in this way, suggesting it can "flow" (and no doubt can be diced, sliced, weighed and stored for future use, like charcoal briquettes), seems very alien to me. "Value", in my mind, is a very complex and vague concept. There's fiscal value, of course. Profit. But businesses have been learning the hard way that such a one-dimensional view of what matters can lead to a very one-dimensional approach to management. Companies that are only interested in profits tend to be so at the expense of other kinds of "value", like satisfied customers, content employees, safe neighbourhoods, clean air, and so on.

Businesses have been learning, albeit very slowly and clumsily, that long-term success comes from chasing a richer, multi-dimensional and balanced set of outcomes. They are also learning that, like all multi-bodied problems, these outcomes interact and affect each other in complex ways. Who knew that improving the quality of your products could actually reduce costs, for example?

To suggest that this complex web of interconnected "things" can somehow "flow", to me, sounds as bizarre as proposing that "happiness" is rectangular for easy stacking.

The reality is so much richer and nuanced and unpredictable, of course. It is not like sorting out blockages in your plumbing, or hot-rodding an engine. A does not necessarily follow B.

The most damning indictment of process improvement is the widely-accepted fact that good developers tend to produce better software. All the tweaking and Six Sigma-ing and Lean-ing in the world won't make a piss-poor team appreciably better at delivering "value", any more than it could make an orchestra any better at playing Mozart.

Did it occur to anyone that the folks at Toyota just got better at making cars?

And it's not without it's unpleasant side-effects, either. Many methods focus on reducing "waste". Lean goes the whole hog and suggests that if we reduce waste, we improve the "flow of value". This has a very definite "profit vs. loss" feel to it. It is distinctly one-dimensional.

Complex systems need a fair dollop of waste. Waste might come in the form of unsuccessful prototypes, or a range of choices, or a level of redundancy. We only use 10% of our brains. Most of our DNA is "junk". Many species fail to flourish, ending up as food for the ones who do. Is anyone suggesting that removing 90% of my brain would make me smarter? Or that removing my junk DNA will make my childern healthier and stronger? Or that only successful organisms should be allowed to be born?

My point, laboured as it is, is that in many cases "waste" turns out to be there for a very good reason. In creative and innovative persuits, which are inherently novel and therefore unpredictable, who can say what will never be needed?

The adaptive capacity of a complex system necessitates some waste. Some choice. Some diversity. Some redundancy. Some slack.

In this respect, the likes of Six Sigma are effectively anti-Agile, if we interpret "Agile" to mean "responsive to change". If that's your goal, then focus on the people in your teams, and make plenty of room for their innate learning and adaptive abilities to work their magic.

You may now start throwing the furniture around.

Skepticism Is What Software Development Needs Now

 

I've blogged in the past about the rather alarming amount of hearsay and pseudoscience in software development.

Today I tried a little social experiment. On a social network. Which I thought was fitting.

I asked on Twitter whether typing speed was a significant factor in programmer productivity. As far as I'm aware, there's no data on this, so the answer of a scientist would have to be "we don't know". You may have your theories about whether it would help with flow if you typed faster, or whether writing more code in less time would mean you make more mistakes and waste even more time fixing them. But none of these theories has been put to the test.

Bottom line is, we just don't know.

I got quite a mix of responses, many of which had similar theories. But few said those magic words: I don't know.

As it happens, there's a whole bunch of stuff we just don't know in software development. Most of the accepted wisdom can be traced back to proclamations made with little or no evidence to back them up.

Refactoring makes change easier? Does it? I mean, really, does it? Where's the evidence to support that?

Sure, there's plenty of anecdotal evidence. And I'm every bit as guilty of saying with an air of certainty that refactoring makes change easier and other spurious proclamations. But there's plenty of anecdotal evidence for alien abductions, faith healing and the Loch Ness monster.

Now, I'm pretty sure refactoring does make it easier to change software, if you do enough of it and do it effectively. But I have not a shred of convicing evidence for that. I just believe it. Very strongly. Probably as strongly as Tony Blair believes bombing civilians in Iraq was the right decision. He is very, very wrong. How do I know I'm not wrong about refactoring? I don't. I take it on faith. Which isn't good enough, really, I'm afraid.

If we're to distinguish ourselves from the loonies sittings out in the Nevada desert wearing tin-foil hats waiting for aliens to show up and give us world peace, we need to start adopting a more practical kind of skepticism, and start subjecting some of these old wives tales to a more scientific kind of scrutiny.

SPA2009, SC2010, Carpool & General Nonsense

 

Just a quick post today with a few honourable mentions.

Firstly, SPA2009; with all sorts of stuff going on at the moment, I only managed to make it to one afternoon yesterday, which is a shame because it looked liked it was going swimmingly. SPA's a much more sophisticated affair than SC2009 was (though cheap and cheerful has its place, I should add), and hats off to the organisers for putting it all together. I'm due to be in town later this afternoon, so maybe I'll try and hook up with a few folk after the conference for a beer.

My own session at SPA was fun, but poorly attended, I'm afraid. I enjoyed it, anyway. And that's all that matters, I s'pose :-)

You can view a Flash demo of the practical elements of the session by clicking here. Alas, what you will have missed out on is the experienced insights of people like Alan Wills, Dave Cleal and Mark Dalgarno at the session itself. But I'm sure you'll get the jist of it.

On the subject of Flash demos, I just checked my stats on Libsyn and it looks like the TDD in C# demo has now been viewed 3,000 times. Which is nice. Remind me to do a Java version soon.

Finally, a quick mention about next year's Software Craftsmanship conference.

It's on.

In exactly what form remains to be seen, but I'm committed. And if I'm committed, that means it's happening. Even if it's happening in my flat. I can't tell you too much at this early stage, because there are lots of decisions that need to made, alliances that need to be brokered and sexual favours that need to be administered to make a conference possible. What I can tell you is this:

1. I'm banning talks, presentations or any other kind of session that doesn't involve real live coding. The feedback has been very clear about this; the best bit was getting a bunch of smart, talented and skilled developers around some code and talking turkey with real, concrete examples. I was impressed by how powerful that simple act can be when I used to take teams into a room with a laptop and a projector for a week or two and we'd take turns at the keyboard implementing solutions to real requirements. It's a great way to bring everybody to the same page quickly and with a lot less blah blah blah. And I feel very strongly now that this is the way forward for SC2010 and hopefully beyond. Let the code do the talking!

2. We're going to sort out network access, source control and other technical stuff this time around, so hopefully the first twenty minutes of your session won't be taken up with folk handing memory sticks around. We'll also keep copies of all the code that gets created, which will be donated to medical science for their secret occult experiments. Or something like that.

And while we're on the subject of software craftsmanship, in answer to one Tweeter's question - no, not everybody who promotes craftsmanship necessarily thinks they're a "master craftsman". Far from it, in fact. Don't be bullied by this sort of anti-craftsmanship rhetoric. If you go out there and push the craftsmanship message, you are doing a good thing. It doesn't make you arrogant or elitist. It does mean that you care, and that you at least aspire to high standards. Any negativity or animosity some people might voice about this nascent movement, I suspect, says more about the naysayers than it does about the size of your ego.

My ego, of course, is massive and I do - as the same Tweeter kindly pointed out in a private message to me - have a very high opinion of myself. And why not? I still hold the self-endowed title of "World's Greatest Software Developer" and nobody has challenged me for it yet. I am also a brilliant rock guitar player, Kung Fu fighter and I'm fantastic in bed. But that has nothing to do with my support of software craftsmanship. I'm just a big-headed gobshite who just happens to care about software development. I'm perfectly comfortable with that. Hey, it works for me :-)

Anyhoo, I'm off to watch this week's Carpool (highly recommended, by the way) before I launch into some actual work. Toodle-pip!

The Movement Formerly Known As "Software Craftsmanship"

 

As with all intellectual movements, it seems the mere act of choosing a name is enough to stoke up heated debate.

It's actually not possible to use words currently in existence because they all have some kind of semantic baggage, and someone, somewhere is going to take offence somehow.

One possible solution is to take a leaf out of pop singer Prince's book and adopt an abstract symbol that's currently not in use.


The Movement Formerly Known As "Software Craftsmanship"

But then again, if you've ever taken the ink blot experiment, you'll know that even abstract shapes can get people hot under the collar.

On a related note, while some argue over the name, others continue to argue over what it is we actually believe in. Already there's a manifesto that's generating fun and games on discussion groups and blogs around and about the countryside. Meanwhile, a few folk seem to be venturing out into the Cursed Earth to preach the good word of Software Craftsmanship - from what bible I do not know, because we're still writing the outline.

Certainly, there seem to be different schools of emerging. Some, for example, see apprenticeship as a key requirement. I don't. Don't get me wrong, I think apprenticeships is a potentially great way to learn and improve. No argument there. But are there other ways? And are the people who tread that other path really "software craftsman"? (Sorry, are they really ...) Yes, I rather think they probably are.

Which all brings me to the conclusion that we may be overthinking things. Again. Because we're like that.

Burn The Perfectionist!

 

As soon as I get a chance this weekend, I'll be doing a write-up on Thursday's Software Craftsmanship 2009 conference. But I just wanted to share a thought before then about the debate that's been bubbling away on various blogs, discussion groups, lonely hearts classifieds and electric parsnips about this craftsmanship metaphor.

To me, at least, it's not a metaphor. A craftsman is someone who applies skill and care to the creation of a high quality end product. It is in no way metaphorical or analogous to call someone who applies skill and care to the creation of high quality software or systems a "craftsman". But that's just my opinion, and if we temporarily put aside the fact that I'm always right then there are some interesting philosophical discussions that you can have on that. None of which will probably help in any practical way to move our profession forward.

But such debates and navel-gazing can be very entertaining and it keeps the more introspective of minds occupied, lest they fall prey to darker thoughts and whimsies, I s'pose.

The other thing I've noticed is how some people view this whole craftsmanship phenomenon as a form of elitism or extremism. And they're quite right, of course. Anyone who expects software developers to take pride in their work and to only ship code they feel they can be proud of is obviously a babbling lunatic or some kind of super-advanced alien lifeform from the planet YAGNI.

To suggest that software should be as good as we are capable of making it, and that we should constantly strive to raise that bar, or that we shouldn't ship code until we are happy with its quality, is heresy of the worst kind, and anyone who dares even to whisper such blasphemies in the presence of the High Priests of Pragmatism must be burned at the stake so we can prevent these very dangerous ideas from spreading (especially to the Visual Basic community, who can be highly impressionable, as you know).

These words - "pragmatism", "perfectionist", "extreme", "dogmatic" - they have strong emotional connotations in business. No matter how reasonable and well-supported a person's point of view is, accuse them of being "dogmatic" or a "perfectonist" and customers and managers will react instinctively to neutralise the perceived threat in their midst. They won't pause and weigh up the arguments and the evidence. They'll just make an instant knee-jerk decision because, in business, words like that usually trigger deeply-rooted primal reflexes. "Burn the perfectionist!" they'll scream and you'll soon find yourself being carried down to the Job Centre on the shoulders of an angry mob of pragmatists.

I'm discovering that there's little point in engaging in debate with these people who cite "pragmatism" as a justification for lowering our already-way-way-too-low standards of professionalism and quality. 20 years of industry studies on the relationship between quality and productivity have shown beyond any reasonable doubt that it's a bogus conflict.

There are, of course, very expensive and time-consuming ways of achieving high quality software. Testing your software after it's been delivered, for example, is a very expensive way of catching requirements misunderstandings. In fact, it's about 100-1000 times as expensive as testing your understanding of each requirement before you implement a solution for it.

Anyone who has failed an exam because they misunderstood the question will tell you that taking time to read the questions carefully is actually very practical advice. That's real pragmatism. You do it because it works, and not just because you're afraid to say "no" to some customer or pointy-faced boss or because you don't have time to learn a better way.

And it does work. Defect prevention works. Period. There's really no reasonable doubt about that.

Ironically, the reason why "pragmatists" don't have time for niceties like adequate test automation or enough refactoring is because they are too busy dealing with the far more costly consequences of not doing these things in the first place. So they're stuck in a vicious downward spiral where release after release the crippling burden of crappy code and costly manual regression testing sucks them ever deeper into the abyss. The only way they can get back to the surface to draw breath is to start making much bigger payments against their technical debt, if they're to have any hope of getting it down to a manageable level where they can start delivering value to their customers again.

Anyway, that's my Saturday rant. I'm off to Planet YAGNI via the medium of pure thought to waste 10 billion man-hours attempting to perfect a single line of code with all my colleagues from Mount Olympus.

Are We No Better Than Those UFO Nuts? The Case for a Software "Enlightenment"

 

Back to the subject of UFOs and the paranormal...

One thing that I find very entertaining about the UFO community is how authoratitive they manage to sound whilst piling speculation on top of conjecture on top of supposition on top of a very shaky bedrock of fundamental assumptions.

While less colourful students of the phenomenon dare only to ask "are THEY here?", many UFO "researchers" settled that debate decades ago in their own minds and are now preoccupied with more advanced questions like "are the small grey insect-like aliens at war with the tall lizard-like ones?" and "what does the High President of the Galactic Federation think about this whole Isreal/Palestine thing?"

Check out this classic example of the ouvre from self-styled (and what a style that is!) UFO expert Ed Komarek. How many totally unsupported claims did you count?

It's easy to laugh, of course. And, yes, I do think these folk are either completely ga-ga, or just plain crooked and they know they're making it up. The poor, ignorant saps who eat this stuff up from UFO fanzines ('cause that's what they are, folks - it's a cult of personality) and blogs and discussion groups are being led down a very long and windy garden path by charletans and nutcases who are every bit as screwy as astrologers and mediums - and priests, let's not forget.

At best we get pseudoscience. At worst, just plain drivel without even the shallowest attempt to justify it scientifically. UFO lore is 99% "he said, she said", with researchers relying mostly on anecdotes and spurious official memos to back up their outrageous claims.

But when I read the books, magazines, blogs and message boards of our illustrious software development community, I'm ashamed to say that we are equally piling speculation upon conjecture upon supposition on top of a very, very shaky foundation of assumptions. Pseudoscience is rampant in software development. Long-since debunked (if they ever were talen seriously) pop psychology and sociology, and totally antiquated or beyond-the-edge-of-the-fringe management theories abound. Everything from Myers-Briggs Types to the masterpiece of pseudoscience that is the Theory of Constraints - our profession is stuffed to the gills with unproven management theories that are actually nothing more than old wives tales and voodoo.

And it doesn't stop there: alarmingly, much - actually most - of what we say about writing software itself is also just a load of old mumbo-jumbo when you scratch beneath the thin veneer. A lot of the received wisdom about software design has not been validated by experiment, and the causal mechanisms behind so much of what we consider to be good or bad design choices are simply not understood.

And for every one of us who seeks empirical answers through some kind of testable theory of "code mechanics", there are 100 more who are quite happy to believe that you should not use the Singleton Pattern simply because "the book said so".

Just as for every person who seeks scientific proof of alien visitation there are 100 more who are happy to accept that they're here - or, indeed, not here (because both positions are unscientific if they're based only on faith) - purely because Stanton T Friedman or Nick Pope says they are.

As software developers, we are living in a dark age of ignorance and superstition, and one of my great hopes for the next decade is a resurgence in interest in the science of software (as well as a surge in practice of the craft of software development - because the two are by no means mutually exclusive) and perhaps one day we'll look back and call this transitional period the software industry's very own Enlightenment.

We're Doing Agile. So Why Is Our Code Still Crap?

 

There's a debate bubbling away on James Shore's blog post about The Decline And Fall of Agile

I waded in a couple of times, and feel so strongly about the points I've raised that I thought I'd copy and paste the second comment here for your delight and delectation:

I work with a lot of teams who are struggling with the apparant paradox "but we're doing Agile, so why is our code still crap?" Very often a little bit of analysis of their end product reveals that they're actually not really doing many of the practices they claim to be.

They might, for example, believe that they're being test-driven, and yet a simple test coverage report might reveal that the majority of their code must have been written without a failing test that required it. Or they might think they're doing refactoring, but a bit of digging reveals a huge backlog of code smells and crippling levels of technical debt, for example. (And, let's be honest, when you actually pair with them, "refactoring" usually just means "hacking about randomly in the code").

It's the most common anti-pattern I see among Agile teams: the "oh, but we're different" syndrome, as they point and laugh at "lesser" non-Agile teams who are, in most practical senses, actually producing software that's no worse.

The first episode of the TV comedy "Nathan Barley" - written by the brilliant Charlie Brooker - has some useful insights into this. In the first episode, down-at-heel journalist Dan Ashcroft writes a scathing attack on fashion victims and new media trendies called "Rise of the Idiots", which is then feted by the very people he was attacking (Nathan Barley in particular), who genuinely believe he was writing about "someone else".

Talking about brilliant Guardian columnists, Malcom Gladwell has written a very thought-provoking piece this weekend on the relationship between practice/application and "genius". The magic number seems to be 10,000 hours - the time it roughly takes to become brilliant in some complex discipline.

Rant II over...