I came across an interesting post here on why Betfair should fear whatsapp. Strange bedfellows for an article but the general thrust of the piece is that a chat application is similar to a financial exchange, in this case Betfair, and could theoretically disrupt its business model. I have to be honest and say it’s something I’ve never thought of.
If you read what’s said then you might think that this is so. The author goes into some detail about the similarities and given the depth of knowledge in some of the other posts on his site you might think that he’s got a point. He even says straight out that “A betting exchange is really just a chat application – in place of messages, you have bets; in place of chat groups, you have markets; and in place of the chat transcript, you have the order book“.
If you haven’t seen this awesome parody video already, you need to. It’s a great example of what it can sometimes feel like as an expert in a meeting with non-experts.
Buzzword bingo, massive management overhead, ignorance of implementation details, solutioneering, management shutting down needed discussion, condescension, it has pretty much the full package of the worst the world can throw at you.
Of course it’s a taken to the furthest extremes otherwise it wouldn’t be funny but if you’re don’t think there’s a grain of truth to it, ask any technical person if they’ve ever been in this sort of situation and see what they say. It’s not that techies are geniuses and everyone else is an idiot, it’s just that without sufficient understanding almost any area of technical knowledge can be over-simplified to a level that defies reality. This is true for science as much as it is for technology.
The thing is, there another message other than experts have to suffer dealing with idiots all the time; it’s that experts need to be better at teaching and communicating to stop this scenario from happening in the first place. Continue reading →
It’s not exactly rocket science or exactly a new idea but how many of us treat our test code like our application? I got to thinking about this when Stuart extended our checkstyle checks to include our unit and integration test code. That simple analysis threw up over 300 violations. The vast majority were ones that we ended up suppressing like magic number and visibility modifiers but there were plenty of minor annoyances like various import violations and whitespace violations. Checkstyle is a great starting point but ideally we would want to have our test code undergo the same sorts of static code analysis as our normal code: cyclometric complexity, LCOM4, duplication, package tangle index and whatever else other than code coverage your tool of choice provides.
Apart from being one of the ‘ooh shiny!’ aspects of Agile (and we all know that Agile is the one true way) what it does it ensure the code quality of your test code is the same as the rest of your code. This enforces good code practices and minimises the amount of kruft that can get in your test code and when it comes to refactoring you’ll have a much easier task.
Personally I’m a huge fan of Sonar even if you have to perform little bit of sleight of hand if you have cobertura installed in your maven pom file so that it breaks the build at the test phrase (fast feedback please!) but it really does do everything you need. Once you get your test code hooked up too, you’ll get the same benefits that your application code gets and you’ll thank yourself in the long run.