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.

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!!