Leaning towards java

Archive for March, 2009

Just to drive the point home, guess what just brought down our latest release. A combination of Property accessor logic and not knowing what the underlying framework does, or does not do.

Now I believe this to be fairly harmless getter, we keep a history of dates and the current date is the first on in the list (its sorted). So if there is a list, and it has an entry, get the first one otherwise return null. Simple

The problem is only that when checking if we have a list, it turns out the underlying framework hides the collection away in a hashmap. As a result in some instances the hashmap is touched by infrastructure code which adds a null to it, thus a check to make sure the returned collection is not null need to be in place.

There are three points here

Dont put frickin’ logic in proerty accessors

Know thy framwework, inside out especially if its hand rolled. You will not get maqilinglists with answers

There are good frameworks out there, so If you handroll your framework, make sure it doens’t do stupid things.

In my rss reader there is usually a great deal of wisdom appearing each morning, and today was no difference. But its not often you get one of your problems, described in one and have it partially answered in another.

David Christiansen, author of the superb Technology Darkside blog tells this story, and I can see great similarities with corporate IT. In this case David talks about a dysfunctional team of consultants, but isn’t the same game played everyday in corporate IT? I think its called politics. So take those points and add

All this, and many more, in order to keep climbing that corporate ladder. It takes a good manager to recognise these and the fact that they are counter productive and to take actions against it. One very effective cure to these things is to create total transparency to promote recognition by merit. The way Jurgen Appelo describes it here makes perfect and powerful point. One of my previous project managers didn’t actually post the salary spreadsheet on the wall but he threatened to and the effects were quite interesting.

But while this is very contentious, there is plenty of information that is not so and there are lots of tools out there today that makes information about your projects and product readily available. Why not let your continuous integration tool (you do have one, right?) generate a project report each night and publish it to the intranet. And while we are talking about that nightly build, it will break and when it does – make sure its very public, and slightly embarrassing. Project reports could also be public knowledge, which project managers are continuously over budget, which developers keep underestimating their efforts, which testers can’t find bugs? But more important than showing shortcomings, achievement can publicly proclaimed and rewarded. When the builds haven’t failed for a week, its the team leads responsibility to buy the first round of beers, or get that Friday sugar high going creating that sense of collective achievement.

After all, until this information is in the public domain, how are you going promote recognition by merit? Lets hope more
corporate IT departments are opening up to Agile and Lean, where
openness and teamwork is the norm.

Generally I admit I default to adding getters an setters, quite often just to offer sacrifice to the java bean standards, even though this is very often just noise and syntactic sugar. But I’m always wary when I see logic in a getter/setter, the example in this article is a fairly harmless one (as in its unlikely to break the application). I’d be quite reluctant to do a redirect in a getter, thats just evil. Imagine trying to find that bug. The basis of that is that getters, when it comes to Java in particular, are so frequently used by ‘infrastructure code’ that you’re not 100% in control of (which of course Reflection is to blame for but that’s another story) . This opens up for way too many wtf’s in your everyday life.

The struts form getter is called from a jsp, but since we’re also using apache commons reflection util to populate/scrape values from the form, and this field masquerades as a proper Bean property,this code gets called 3 times per page load. No wonder the error log is spammed with errors when the domain objects aren’t behaving.

And a few days earlier I had I discovered this piece of code, checked in over 3 years ago which just clearly does not do what it says on the tin

Now this is just poor coding, I know and this is nothing code reviews will not cure, but personally, I’d quite happily do without these kind of surprises, which makes removing the getters/setters all together quite attractive. They should most certainly come with a license.

The point is, if you are putitng any non trivial logic in your gettters and setters, you need to think long and hard about where they are being used, and then reconsider your decision.

This idea has been knocking around in my head for a while, but I’ve never really gotten round to it, which is a shame. I do have a lot of opinions about a lot of things that go in in the weird and wonderful world of software development (and other things as well, of course, but they will not see teh light of day here) and when my collegue, after some email ping-pong, said ‘we need to get this guy an internal blog and set up RSS feeds instead’ I knew exactly what to do. And here it is, finally…

It is a bit daunting though, there are so many intelligent people out there who are ready to pounce on any mistakes and to be fair, I make quite a few. But what the… what doesn’t kill you make you stronger. So lets plunge in…