« January 2005 | Main | March 2005 »

February 25, 2005

The difference between knowing and understanding

I suspect that the vast majority of us carry around a huge arsenal of "best practice" idioms - the veracity of which, like Martin Luther King, "we hold to be self-evident". Indeed, the whole Patterns movement has come about to spread this collectively-gained knowledge and prevent the endless rediscovery and reinvention of the wheel. Having such information readily on hand removes the need to suffer the pain arising from violating these idioms. Something along the lines of "if we have seen further, it's because we've stood on the rotting corpses of previous development teams".

Yet yesterday I received one of those harsh slap-in-the-face lessons that occurs when you're forced to deal with a violation of these central tenets of good software design. The context was a refactoring session and the problem was caused by code ignoring the classic "separation of command and query" principle. Specifically, my pair and I stumbled across a method which at first glance looked like an innocent accessor (i.e., getFoo()). We were refactoring the class containing this code and one of it's clients...

Suddenly, the test we were running began behaving in a very strange fashion: seemingly, the code in which our breakpoints were positioned was no longer being executed! This confounded our two little brains for some time before it became clear what had happened: the practical upshot of refactoring out the call to our now no-so-innocent getFoo() was that the side effect it contained (which had previously resulted in our breakpoints being triggered) was no longer occurring. What we thought was a simple query method contained an undocument command that changed the state of the class itself! D'oh!

Now I'd known of the separation principal for many a long year, but it had become such a sub-conscious thing that I never really appreciated the damage that violating this principal can cause until I stood toe-to-toe with this delight yesterday. The end result is that I'll be super-duper careful of this issue from now on and hunt down offenders with a fanatical vigour. But I almost regret not having similar exposure to other such violations in order to harden my resolve in those directions as well. After all, there is a world of difference between being told a kettle sitting on the stove is very hot and receiving a nasty burn from the same.

Posted by Andy Marks at 10:57 AM | Comments (0)

February 22, 2005

Java Mock Object Framework Comparison

I gave a short presentation at the QJUG last night on a number of current frameworks for generating mock objects in Java. I chose the three "big names" in the mocking space (EasyMock, DynaMock, JMock), plus a quaint fourth in MockCreator, and MockRunner for a bit of variety.

Here is a HTML version of my slides (not that they're really that informative without the accompanying witty repartee available only to those present), along with all the source code presented.

I've left obtaining the necessary JARs to compile/test the code as an exercise for the reader :-)

Anyone who'd like to solve the problem I had getting MockCreator blocks to work properly - I'd be most appreciative.

Posted by Andy Marks at 03:51 PM | Comments (1)

February 15, 2005

How Wrong I Was!

I've come to a rather humiliating discovery over the last six months or so, as I've been cycling to and from work each day on the fabulous bicycle path along the Brisbane River, a discovery which has forced me to fundamentally change one of my basic ideas behind people and transport. Let me explain...

Up until recently, I've been a firm believer that drivers are, to a greater or lesser degree, big, dumb, stupid animals that should be best avoided at all costs. As a (again, until recently) committed and vocal non-driver, this opinion has been formed over years of near misses as a cyclist, motorbike rider and, to a lesser extent, pedestrian. My conclusion, although general, gave me the mindset to behave in a manner most likely to keep me alive and safe: in other words, treat all drivers as idiots and you'll rarely be disappointed.

The counterpoint to this theory was that non-drivers (and I'm talking mainly cyclists and motorcyclists) were correspondingly benevolent and wise, given the greater sense of commitment they have to safe behaviour on the roads...

I'm now not so sure this is the case!

The sort of shenanigans I've seen from my cycling bretheren along the Brisbane River bike path has honestly made my hair stand on end at times. Literally every single day, I'm witness to cases of selfish riding in respect to pedestrians that put most drivers to shame. It seems the worst possible thing a cyclist can do on this path is slow down for whatever reason, and they'll resort to any number of risky actions to prevent this from happening. These actions include, but are not limited to:

And to those of you who think these things are not important because it's not on public roads, I invite you to become an intimate participant in a head-on bike collision at a closing speed of around 60kmh and then reconsider. Just because there are no road rules being enforced, does not mean you can put your brain in neutral and endanger other people's travels solely for your benefit.

Shame, shame, shame Brisbane River path cyclists! Both for acting like utter gits, and for forcing me to eat my words and reconsider my postiion on this topic.

Posted by Andy Marks at 06:11 PM | Comments (5)

February 11, 2005

Always check your blind spot!

As I left work last night, I'd just caught wind of a bug in the piece of code I was working on. From the gist of the bug, and my familiarity with the code, I quickly came to a pretty good diagnosis of the problem. In short, a piece of code which filtered records based on date were excluding records added on the current day. The code used a predicate in the form:

lowDate <= recordTimestamp <= highDate

My hunch is that these new records all contain timestamps along the lines of dd/mm/yy hh:mm:ss, whereas the highDate contained dd/mm/yy 00:00:00, so any record created on the day will be excluded based on the fact that almost any value of hh:mm:ss is not less than or equal to 00:00:00 (except for those lucky enough to have been created exactly at midnight).

After a bit of thought, it occurred to me that I'd introduced this problem before...

On my previous project...

Further consideration brought forth memories of other projects gone past where I'd also written this bug into the code.

In fact, I'm fairly sure I've seeded this nasty into the codebases of almost every project I've contributed on in the last 8 years or so!

A definite blind spot in my developer mind. Either that or the symptom of some Manchurian Candidate-style brainwashing... to what end, I'm not entirely sure?

Perhaps I should just insert the failing test case into the test suite of every new project I work start on, to head off the seeming inevitability of this bug reappearing.

Posted by Andy Marks at 07:30 PM | Comments (0)

February 09, 2005

Collective code apathy

Some time back I was waging a lone war against the XP practice "collective code ownership" as it was defined on our project. The standing definition/catch phrase was "no-one owns the code". When I first came across this term, I initially thought it was just a typo but it became clear that this was written exactly as it was intended. Furthermore, try as I might, I was singularly unsuccessful trying to explain why I thought this was entirely the wrong way to express "collective code ownership".

Recently, this issue crept into my mind again and, as things tend to do, distance and time clarified my muddled objections to this phrase... via a potentially weak analogy :-)

Scenario One: A company goes bankrupt. A company that I have no stake in. No shares. Nothing. Result: I care not (unless it's someone like Enron where I might chuckle a little).

Scenario Two: Another company goes to the wall. This time I'm an investor, having held shares in the company for several years. Result: I care. How much I care is probably correlated to the size of the stake I hold, but I still care. Presumably, I'd be aware of the problems long before Chapter 12 was the only option and I'd be trying my utmost to not let things get to that point, fairly certain that the other investors would be similarly involved.

Obviously, Scenario Two is the sort of development environment I'd like to work in - one where everyone has a vested interest in the result of the whole exercise. I want everyone to feel that they have a stake in the codebase, so that any signs of distress are treated with the respect and promptness they deserve.

So however inconsequential the original phrase may have seemed, within it lay a worrying assumption about the values held by the team.

Posted by Andy Marks at 03:39 PM | Comments (6)