Having only really dabbled with it before, I’ve been pleasantly surprised now that I’m using IntelliJ IDEA almost full-time. It’s not that it has a single feature that is mind-blowingly ahead of the competition; it’s all the little details that just make it a pleasure to use.

My first “That’s Really Nice” moment was when working with some Spring beans and it understood all of the links between the code and the config. If I hadn’t added a referenced bean, it would tell me. If I type in a bean’s class attribute, it knows that it maps to a Java class and can auto-complete that for me. If you pull in a property file using Spring’s PropertyPlaceholderConfigurer support, it parses the property file so it can auto-complete placeholder usages, give you a hint as to the current value (so you know you have the correct property), and tells you when you’ve typed in a placeholder it doesn’t yet recognise (usually because you forgot to add it to the property file).

The embedded language fragment support, though, is really something else. If you have a Java class that contains a String with some SQL in it, Eclipse will treat it as a String and that’s that. IntelliJ goes a step further. Sure, it’s a String, but it can understand that it’s SQL (or JPQL, HQL or whatever) and do syntax checking for you. It’ll auto-complete keywords for you. Heck, if you tell the IDE about your data-source (presumably a relational DB in this case), it’ll store a bunch of metadata about that data source, and use that to aid you too; by extending the auto-complete to table names, for example.

There are a bunch of other great features in there but, as I say, it’s not the big, shouty features that make it great. It’s the attention to detail in making coding that much easier that makes it such a pleasant experience to work with. I can’t see myself going back any time soon.

In “Avoiding False Metrics“, Seth Godin has a few things to say about the ways in which otherwise sensible people fool themselves into believing they are benefiting, when really they’re playing a crummy numbers game:

At the local gym, it’s not unusual to see hardcore members contorting themselves to fool the stairmaster machine into giving them good numbers. If you use your arms, you can lift yourself off the machine and trick it into thinking you’re working yourself really hard.

Of course, you end up with cramped shoulders and a lousy workout, but who cares, the machine said you burned 600 calories…

We can all see the problem here: people want a result, and will try to take the quickest way of getting there, even if doing so negates the entire exercise.

I can’t speak about other industries, but it’s my perception that software engineering is particularly prone to this way of thinking. Lazy software engineers constantly take tools and processes that are supposed to help us build better systems, apply them in the most perfunctory way and think that’s the improvement made. When we do this, we’re no better than the gym goers fooling the machines and themselves. A few examples…

• Using a Continuous Integration build server does not mean you are doing continuous integration. Too many people think that merely having the CI server is enough. It is not. If you’re making use of a CI server like Jenkins, that’s great: it’s good to know that your code base is broken as close to the point that it happens as possible. But what do you then do about it? A properly run, continuously-integrated project makes getting the codebase back to a clean/green build the highest priority because if you are merging into a broken codebase, you are not integrating: you’re merely piling up damage. If the next person to commit causes a fault and doesn’t know about it immediately because the build had been left broken, they’re not going to fix it when it’s most critical to do so.

  Beyond just having a build server, there is a lot more to successful continuous integration. For example, what’s your branching-and-merging strategy? Do you feature-branch at the start of a sprint? That’s almost certainly not CI. Do you create release branches for going into production and merge fixes back to trunk? Also not pure CI, but possibly an acceptable flavour if you’re managing it well.

  My point is that CI is not just having a build server: it’s having everyone on your team focussed on the goal of a single, consistent, tested, and reliable codebase.

• Coverage does not mean that you have useful tests. Code coverage can be an insidious metric in the wrong hands. Too many people who do not understand it feel that getting coverage to an arbitrary point is, in and of itself, the goal. It is not. The goal is to have every part of your project covered by meaningful and robust tests in order that you can be sure any regressions are found as early as possible.

  By increasing useful coverage, more issues can be found earlier, whereas if we mindlessly write tests to bump up the number, well, that can have the opposite effect. Code designed to merely cover, and not actually test, is often brittle in the face of change. By being about moving a number rather than implementing a check, it’s not tied to the needs of the project in the same way as a real test, and creates greater difficulty when refactoring occurs.Code designed to cover without testing also gives a false sense of security. You might think that your code is being tested and that you’ll be warned about regressions, but if your tests are there just to bump coverage stats it’s more likely you’ll get nothing from them.

  Again, the point is that coverage is merely an indicator: it’s the red light on your dashboard telling you there is a problem. The solution is to find the root cause and fix it, not to cover the dashboard in green lights so you can’t see the red any more.

• Similarly, static analysis tools do not necessarily mean you will have high quality code. Some think that getting your Sonar bugs down to zero is, in itself, worthwhile. It is not. It’s only by fixing the underlying issues in your code that you get any real gains, and these underlying issues are not always what Sonar is telling you about.

  Far too often I’ve seen people get a series of “This Method Is Too Long” Checkstyle errors, and immediately just break lumps of code out into smaller functions. This is not necessarily the right approach. Rather than taking it at face value (“Method is too long? I must need a bunch of smaller methods!”), consider that your abstraction might be incorrect. You might indeed need smaller, better structured methods, but you might equally need to take a long hard look at your class and decide if it’s doing too much. Maybe you need a much deeper refactoring.

  Remember: static analysis tools tell you about symptoms. It’s your job to hunt for the real cause, rather than merely treating the symptoms.

• On the human side, scrums do not make you agile. Scrum is an extremely important and easily implemented concept in the agilist’s toolbelt, and some think by merely getting everyone together for a short meeting every day to get status updates that they will see benefits. They will not.

  Many teams lose the benefits of having a scrum by simply not understanding the necessary structure and strictures, or really understanding the lessons they learn. By reducing it to a box-ticking exercise (“Everyone said what they’re working on, and what they are going to work on so it must be okay”), they negate the whole point.

  Following a semblance of the process is important: every update should be headline only, protracted conversations should be broken out, and everyone in the scrum should largely care about what everyone else is saying. If you fail on any of these points, then you’re simply wasting everyone’s time and missing the point.

  As with most good practice, the point of a scrum is to minimise the delay between a problem being identified and it being solved. This might be by someone hearing an update and saying “what about this?”, or maybe being able to help with an identified blocker. It’s not, however, going to happen when sprawling updates, unnecessary information, and long conversations cause half the audience to tune out.

Perhaps it’s because we’re used to using machines to take shortcuts in otherwise challenging and tediously manual work that we feel we can apply these shortcuts without too much critical thinking. This is a mistake that will only compound itself.

Five movies for May…

First up is Marvel’s Avengers Assemble: the ending for the Phase One of Marvel’s relaunched movies, bringing together the Iron Man series, Incredible Hulk, Captain America and Thor. Was it worth the wait and hype? In short, yes. It’s a hell of a pay-off we get from this Whedon directed entry in the series. It manages to balance character growth while servicing a massive cast, constantly pushing forward the world-threatening plot, getting a few decent laughs in, and, most importantly, a visual treat of an action film. If you’re pre-disposed to hate action films, then all I can say is that this is the blockbuster done right. Yes, it’s over-the-top action, but it doesn’t sacrifice everything else a film should be to service more explosions. An extremely strong final chapter in this series, that makes me look forward to phase two. (See my The Avengers Twitter review).

Meanwhile, American Pie: The Reunion does not fair so well. Revisiting a long gone franchise (well, long gone if we ignore the embarrassing straight-to-DVD sequels, and we do ignore those) is a difficult thing to do, but perhaps worthwhile if we can get a new perspective on the characters. The writers try to show us how these teenagers have grown into adults, a decade on, and the effect that’s had on the shenanigans in their lives. It doesn’t do so well. It spends a great deal of time retreading old ground, and trying to service every major character in the franchise and, frankly, it does a bad job of it. The handful of genuinely funny (new) bits were all in the trailer, leaving the film with a few chuckles. It’s not awful, but it is completely unnecessary. Only for die-hard Pie fans. (See my American Pie: Reunion Twitter review).

Jeff, Who Lives At Home sees two very different brothers (and their mother) spending a day learning to throw away their hang-ups, and live in the best way they can. It’s a little schmaltzy at times, and is certainly flimsy, but it’s a pleasant enough way to pass an hour or two. (See my Jeff, Who Lives At Home Twitter review).

Sacha Baron Cohen’s The Dictator tries to take the styling of his earlier work (where he’d play a terrible character and let real people play against it) and apply it to a more traditional film. The results are extremely uneven. It works best, surprisingly, when it is going a little bit too far and is being mean-spirited, because it’s done with such childish malevolence. When it tries to settle down into plot and character building, it’s very badly done. Cohen can act, as evidenced in Hugo or even Sweeney Todd, so to see so many lines delivered limply here is disappointing. There are moments of comic genius here, but it’s largely disjointed and poorly made. (See my The Dictator Twitter review).

Finally, The Raid is an extremely stylised and thoroughly enjoyable Indonesian action film. It strips away the plot to the bare minimum, and focusses on it’s hellish premise: a SWAT team that has been decimated and caught in gang territory, trying desperately to escape the tenement slums. Some of the action sequences are absolutely stunning, and the fight choreography is worth the admission alone. I’d liked to have seen a few longer takes, to really show off, but that’s nitpicking. An extremely good take on the action movie. (See my The Raid Twitter review).

The winner, then, is Marvel’s Avengers Assemble. If you’d asked me a few months ago if I thought this would be good, my guess would have been ‘no’, but I’ve been gladly proven wrong.

Just three films in April’s Film Fight…

First up, The Kid With A Bike is a missed opportunity. It tells the story of a small boy who has been abandoned by his family, for reasons that he doesn’t really understand. It’s about him coming to terms with the anger he feels, the difficultly he has in making new relationships, and the mistakes he makes. What should be a sad piece (possibly with a hopeful ending), doesn’t do the subject any justice. Through failings in pace, dialogue, and direction, it fails to bring any weight to the boy’s situation. We end up with a smattering of events without the feeling of any deep consequence. A shame. (See my The Kid With A Bike Twitter review).

Sean Penn finds a role that is surprising even for a seasoned character actor like himself in This Must Be The Place. Penn plays a fragile and quiet goth rocker, coming to terms with the death of his estranged father while coming to some realisations about the emptiness of his life. Penn’s performance is, as always, something to behold. For a man who has portrayed so many strongly driven characters, it’s eye-opening to see him play someone so meek. Sadly, the rest of the film does not live up to the lead: it’s a slow, meandering slog where not enough happens over far too long a period. It’s difficult to watch, not due to the subject, but simply because it is largely bereft of worthwhile content. (See my This Must Be The Place Twitter review).

Finally, The Cabin In The Woods has taken years to finally make it to the screen, and it has been worth the wait. It’s in that most troublesome group of films to review; in which any commentary could ruin the first watch, which would be a shame even though it will undoubtedly stand up to many repeated viewings. What can I say? It’s ostensibly a horror film that is about horror films, but it’s also so much more. It’s been put together with craft, style and wit into a package which we haven’t seen before in many years. I’ll say no more other than to say it is excellent. Definitely see this film. (See my The Cabin In The Woods Twitter review).

As should be clear, The Cabin In The Woods is the clear winner for April.

March sees just three films reviewed…

First up, In Darkness deals with a Polish sewer worker using his knowledge of the passages under his city to hide Jews from persecution, for a price. As you can imagine, living in a sewer has a great physical cost and the film shows many horrible moments. However, the film really fails to bring any weight or insight to the tragedies. It fails to make any deep emotional connection. Exactly how or why it failed, I am not sure, but I know this film has been done better before this. Disappointing. (See my In Darkness Twitter review).

Having not read the books and going in with very little knowledge, The Hunger Games was a relatively pleasant surprise. It has serious pacing issues, showing far too much of the story before the titular games and thereby compressing the more important acts to a greater extent than necessary. That said, we do get quite a vivid picture of the world the games are set in, and are left with no doubts about the inequalities in the society presented. For the teen fiction genre, this stands out as quite an enjoyable watch. (See my The Hunger Games Twitter review).

Finally, 21 Jump Street was an excellent surprise. Where I expected yet another formulaic US comedy with Jonah Hill, I actually got something of a classic. It’s just dumb enough to be funny without pandering, it’s self-aware without being groan-worthy, and it’s ridiculous enough to pull in the big laughs without being overly weird. It’s pacy, it tries mixing in a lot of different styles of comedy, and is, most importantly, amusing from start to finish. The funniest film I’ve seen in a long time. (See my 21 Jump Street Twitter review).

The winner for March is 21 Jump Street. The Hunger Games were good, but this comedy was better.