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.

Failmanifesto fail

Someone pointed me to:

http://failmanifesto.org

LOL, but why is Maven singled out as the only technology worth directly criticizing? Surely there's another product which is actually crap worth singling out?

Having suffered for a year with a hideous stinking pile of Ant scripts written by consultants who, for dogmatic reasons never adequately explained (of course), wouldn't use Maven, and yet tried to replicate nearly every compelling feature of it using Ant in a sick twisted evil way, e.g. Ivy for dependency resolution, Maven-goal-style targets and life-cycle hooks and more, Maven is now clearing the air with it's simple sanity.

Yes, it seems like magic, which is presumably why people don't like it because they want to tinker, but it works, and I don't have to read voluminous imported build.xml files to work out how to build something any more, and I can build, test and deploy a web application, it's dependencies AND it's dependent web-applications using a single command line (with the cargo plug-in), and far, far fewer lines of XML.

How to fail in an Agile fashion!

Got a successful but slightly dated web site? Want a new one to compete with the trendies? Here's how you can spend outrageous amounts of money, piss off your customers so as to completely wreak your reputation and your business, whilst all the time seemingly 'doing the right thing'!

1. Give yourself a really tight dead-line.

Nothing focuses the mind better than a really, really tight dead-line!

2. Decide to go Agile.

Cool, super, great... trendy! TDD, that sounds good, it means that not only will be have a super new site, but it will all work first time because we tested it all before we wrote the code! DDD, oh wow, our business guys will practically write the code... BDD mad, crazy! That means our design will actually behave the way we want it to!

2. Bring in some consultants to 'teach you Agile'.

Yeah, what we need here is to be told how to do it, however, we don't really trust anybody except ourselves, so we're going to let the developers buy into this stuff, but actually ignore all the advice the consultants give us, after all we're the ones paying them!

3. Decide to do "green-field".

Good choice! I mean, what with the really tight dead-line and a completely new methology, what better choice is there than to re-write everything from scratch?

3. Decide to write a story for every single feature of your existing web-site, and all the new features you want, and spend several months prioritizing them, re-prioritizing them, planning them, re-planning them, throwing some away, writing some more, re-planning them again...

What better use of everyone's time?

4. Code!

We'd better get cracking, what with all those features to deliver (Agilely of course) before the deadline.

Who needs infrastructure? Architecture? Pah! We've got an Evolving architecture! That's much better than a stupid old 'fixed' architecture!

Anyway, we've got the buzz-words all worked out, so the code has practically written itself already!

5. Detach the most experienced developers from the team.

See those guys? Yeah, the ones with upwards of 5 years of keeping the site running, incrementally improving it and introducing new technologies? The ones who understand the domain better than anyone else? The one's who we just named 'Architects', before we decided to change everything. Yeah them. Let's sit them in perpetual meetings, away from the actual team now doing the development. How better to make sure that they can't influence, help or steer the team towards the goal...

6. Look at the time! Panic!

Oh dear, we've spent all our time shuffling these cards around, entering them into one Agile tracking system, putting them into spread-sheets, entering them into another Agile tracking system, still using spread-sheets, etc. that we've now got nearly no time left!

7. Grow the team... exponentially!

No, we've not read 'The Mythical Man Month', but thanks for suggesting it.

8. Look at the code! Panic!

Woha! Our near infinite number of monkeys sure can write an infinite amount of tests! The build now take 1.5 hours to run! But our lay architects are grumbling the actual code is complete bollocks! How did this happen, when we supplied our team with all the buzzwords our consultants told them we needed (except the ones we didn't like the sound of)?

What we obviously need here is some metrics and some guidelines! Let's waste some more time getting people to produce metrics about conformance to our (non existent) architecture, and then lets totally ignore all the reports because we don't understand them, oh, and some Javadocs would be useful...

9. Good news guys! We got on our knees and begged the business for more time, so now we've got another six months to deliver everything we promised in the first place, plus a whole bunch more they realized we'd missed out.

...time passes...

99. Well done team! In spite of the tough dead-line, thanks to some inglorious de-scoping, coupled with the late nights and weekends, and some heroic efforts of the senior developers we sidelined in the first place (in fact all the stuff we said that the Agile process would avoid), we delivered an alpha and the business LOVE it (and us especially!) because it has some completely trivial AJAX feature the UI guys knocked up in the first week!

Six more months of this and we'll be the most successful team ever! Agile rules!!