Label Me!

The Merseyside Skeptics Society discusses the latest Atheist Bus Campaign which set me wondering. I'm not quite sure whether I agree (or disagree) with Mike, because I'm confused over what he's actually saying, but let's take his lead and use some Venn diagrams to explore the topic, immediately going somewhat nuclear:

You see, I think if you apply Mike's Venn definition of 'Atheist', it makes the opposite point to the one he's trying to make (or maybe the same point, as I said, I'm confused!). To me, the common usage of 'Atheist' is someone who actively acknowledges that they've thought about it, looked at the evidence, and on balance, think that this god bloke doesn't exist, and, by extension, everyone who does think he exists is rather a fool. Mike says "An atheist is someone who does not accept theism", but I think that means "Actively doesn't accept theism", rather than his preference of "Isn't a confirmed theist".

Now, that's more like it. Now I can see that the natural state, like the newborn child, is not to have tried pasta, and therefore not really to have an opinion on it. There are also two other states: to have accepted pasta into your life, or to have rejected it, for whatever reason (carbs are evil, can't take the gluten, etc). You could of course have tried pasta as a child, perhaps given it before you knew what it was, thought nothing of it for years, but then become increasingly disillusioned with it's many varied but basically identical forms, and then gone straight to the anti-pasta group, never to return. Equally, it is possible that, perhaps on his death-bed, someone who formally rejected pasta, decides that they've nothing to loose in hedging their bets, perhaps weakening under the pressure of the somewhat stressful experience of dying, and try a some fusilli.

In any case, I think the point is, in common usage, Atheist, and Agnostic are active terms, not passive ones, and therefore calling a child an Atheist is as incorrect as calling them a Catholic.

And I might even be right considering the dictionary definition, one dictionary (ok, the one that comes with my Mac), says:

atheism |ˈāθēˌizəm|nounthe theory or belief that God does not exist.DERIVATIVESatheist |ˈeɪθi1st| nounatheistic |ˌāθēˈistik| |ˈˈeɪθiˈɪstɪk| |-ˈɪstɪk| adjectiveatheistical |-ˈistikəl| |ˈˈeɪθiˈɪst1kəl| |-ˈɪstɪk(ə)l| adjectiveORIGIN late 16th cent.: from French athéisme, from Greek atheos, from a- ‘without’ + theos ‘god.’

So it is the theory or belief that god does not exist, not the absence of theory or belief.

So, in my opinion, the diagram Mike, and perhaps the bus, need is this:

Rare insight

Sometimes an external consultant really can bring useful insight to a project. In my experience, this is normally when the consultant is an independent, rather than attached to a consultancy agency with something to sell, e.g. either themselves, a product, or their particular flavour of dogma.

We've recently had the pleasure of some consultancy from a very respected industry figure with many years of experience. He's not a stick in the mud, and is au fait with Agile practices and all the latest 'buzz words'. Rather reassuringly, however, he doesn't tend to use the new-speak himself, for example, in his parlance, a bug is still a bug, it's not a 'defect'!

He gave us a presentation today to share some his observations of our general code-base and project, and I couldn't help but grin all the way through.

Firstly he criticised, in his gentle and constructive way, our architecture, with it's MVC and 'Enterprise Architecture' pretensions, where we've tried to force the angle-bracket shaped peg of XML processing into the one-shape-fits-none-shaped hole of Java. He made me wish once again that I'd really stuck my neck on the line 18 months ago and overruled my colleagues on their approach to the page generation architecture.

Then he turned to our code. Apparently we've got the text-book unit-test coverage, which he's never seen before! Hooray for TDD! But wait, unfortunately, it seems most of the tests are pointless! The tests are so tied to the implementation rather than the intention of the code, that changing the implementation, even in a compatible or beneficial way, inevitably breaks the test, which means that there are effectively no regression tests. He pointed his finger at over-use of Mocking.

In general in our code-base, all the interactions of the unit under test with other classes are actually with mocks, not real objects, which, text book though it is, means that your test can pass even though you're calling collaborators with the wrong parameters, just so long as you expected the incorrect parameters and return the 'right' answer! Thus, nothing ever breaks in our '10 minute build', since it's basically a fait accompli, and everything is only really tested in expensive integration or acceptance tests, which means a long and lonely wait at the bus-stop of build.

This somewhat riled the TDD fans in the audience, who's chief defence seems to be 'Well, when I TDD I write better tests than that'. Unfortunately, they have not written most of the code, instead comparatively junior (but well paid) Java developers have, and whether they claim TDD experience or not, they inevitably go down the mocking rabbit-hole, and write this kind of pointless nonsense. I've also seen people stuck for days on 'how are we going write a test for this code (that we've not written yet)', and tried to dissuade them of worrying about it too much, suggesting that they try writing some code first, at which point the dogma-clones get all uppity. Equally I've seen apparently experienced people spending hours effectively testing a framework we use (e.g. Spring), rather than the code that calls it, because the test for our own code seemed so insubstantial.

Don't get me wrong, having tests is good! Essential! No-one in their right mind is against testing! But only if the tests are actually useful tests, that is, tests that help to understand the way code is to be used and prove the axioms that must not be broken by re-factoring. However, TDD, which 'if done properly' encourages you write your tests first, and thus design the code in the process, is demonstrably very tricky to master, and blind adherence to the primary rule, without application of common sense or foresight can be a colossal waste of time and effort.

TDD is another of those TLAs that if you find yourself or your colleagues brandishing it about too much, you need to sit down and think what the whole point of it is, and what you actually want people to do.