I was riding my exercise bike, listening to Stack Overflow #38 when I heard Jeff Atwood and Joel Spolsky say “Quality just doesn’t matter that much.” I nearly fell off my bike.

(There’s a transcript of part of the podcast on Joel’s blog “Joel On Software” if you don’t want to listen to it).

Of course I’m going to say here that I completely agree with Uncle Bob. The more extraordinary parts of the actual podcast come along when Joel attacks the idea of TDD – test-driven design (although he refers to test-driven development):

But the real problem with unit tests as I’ve discovered is that the type of changes that you tend to make as code evolves tend to break a constant percentage of your unit tests. Sometimes you will make a change to your code that, somehow, breaks 10% of your unit tests. Intentionally. [ ... ] And you have to be able to go in and recreate those tests to reflect the new reality of the code.

This stuff is just a sheer obtuse misunderstanding about the very nature of TDD. Uncle Bob takes him to task for it I’m not going to repeat them here other to say I utterly agree with everything Mr. Martin has to say. Go and read the link above, it’s very effective and thorough pulling apart of Joel’s position on the matter.

I just want to talk about some other things, about the nature of software development, as against some of the things that Joel says is the best way to organise development and development teams. Joel just doesn’t seem to get agile engineering practices, and never has, but even  worse, he willfully misrepresents its disciplines and practices in order to demolish a straw man of his own making. The stuff above about TDD is clearly the prosecution’s exhibit A. He’s a respected development guru, and a lot of people trust what he says about code and the business of running a development sales organisation, which I admit, it’s reasonably sensible most of the time. However when he starts to talk about development practices and team organisation, while he says some things that are highly insightful, some of the others are full of horse manure. Or even worse than that, it’s 50% good advice, and 25% outright harmful advice.  There’s plenty of manure spread around by everybody else of course, me included, but due to his position as an exhalted spokesperson, and due to the wrongful nature of the things he says,  I find that his is particularly dangerous horse manure.

For example, all that stuff regarding “developers get offices of their own”. The best teams I’ve worked in are all in the one room, clustered on desks together and as noisy as hell. It’s usually best to put the whole team in a large office space of their own – so they don’t annoy the hell out of other teams. Joel maintains that individual developer offices are the only way – the illusion of the developer as a single genius toiling away in silence – rather than a member of a multifunctional, communicating, effective team. I disagree, and vehemently. Sure a big ‘TEAMWORK’ banner is just self-deception, but effective teams aren’t make effective through slogans and exhortations. Effective teams are made through actual action. If you have offices, they should be large team-based spaces where whole teams are co-located. And small temporary, hot-desk’d offices, if for good reasons, a developer (or better, a pair) need some quiet time to concentrate on solving some particularly hard problem. But mostly, delivering effective software is about team communication, not developer concentration.

Joel’s totally focused on the notion of the hero-developer.

There’s a bell curve of developer ability (like all such talent) which guarantees the vast majority of developers are “average”. Focusing your effort on finding only the top 5th percentile for your team is futile. Especially when you’ve already got a team you have to work with. Are you going to fire them all if they don’t come up to standard? Or just fire maybe the incompetant ones and work to improve the team. Sure, when you find you’ve got one of these “rock star developers” on your team, maybe you do have to treat him (or her) a little different to the others, to keep him (or her) motivated and interested at the tasks you offer. Nonetheless, 70% of your developers are going to fall within the standard deviation, almost by definition. An additional consideration is, you can get an absolute genius developer who is a complete social misfit and can’t work in a team very effectively. We all know (and maybe some of us are) this guy. At the end of the day sometimes these people are destructive to teams – reducing the teams productive capacity, if they can’t play nice with others. I’m not advocating some sort of we-are-all-mediocre approach and, yes, everyone’s an individual – but we do generally have to work in teams in order to achieve productive software development outcomes.

It’s the agile approach to value ‘people and interactions’ over ‘processes and tools’ but also notice it’s people, in the plural, and not individuals, and interactions implies work is multiplied when those people exchange information effectively and work together as a team. Information exchange bandwidth is greatest face-to-face, or better yet across entire teams. Private conversations that can’t be interrupted are only useful in the context of personal, and therefore truly private, information. Not team interactions. Any team member should be able to ‘stick their oar in’ on any matter being handled by the team – that’s how you get the best ideas! The idea of hierarchicalised, compartmentalised, information exchanges in the context of a private office sounds to me like an MI6 operation, not a software development practice.

Joel might know heaps about the micro-algorithms of manipulating data structures and carrying out instructions efficiently but ultimately it’s the macro-algorithms as to how software is effectively developed and how teams can deliver the best and quickest value to the customer that are the really hard problems. These are also the very problems that IT the whole world over have with the greater business world – how to prove to them we can organise, manage and deliver development effectively. Wearing a pointy hat and talking obtusely about pointer arithmetic and demanding expensive offices for all the prima-donna developers you’re going to employ to toil away in silence won’t convince the suits in charge of the actual money of anything other than you’re a crazy nerd who can’t be trusted with a budget.