Archive for May, 2010

Sermon on the mount(8).2

May 17, 2010

Code reuse has been one of the most persistent buzzwords of software development for as far back as I can remember. It seems to be the sensible thing to do, after all, we’re doing it all the time with our own code, we’re using third-party libraries written by dedicated but random people across the world and it’s all fine.

Why is it then that in a corporate environment what starts out as “Share and Enjoy” often turns into “Go Stick Your Head in a Pig”? The symptoms are varied but all too familiar: after a brief honeymoon people discover that changes in shared code result in cascades of bugs, then either a multitude of near-identical copies of the same code spring up or a paralysing fear creeps over the department, locking every system into using sub-standard code. Either way, after a couple of years nobody quite remembers what had happened, and memory only survives in the form of rituals and taboos.

As far as I can tell, there’s only one fundamental difference between successful and unsuccessful code reuse: knowledge of purpose. Failed attempts always turn out to be based on behavioural similarities only. Successfully shared code serves a clear purpose and that purpose is known to all parties, authors and (re)users alike. And that brings me nicely to the second part of my rant: in-code documentation.

Why is it that we so keenly document what a piece of code does but very rarely state its purpose? When you think about it, it’s quite stupid: after all the code tells exactly and quite clearly how it works and if it doesn’t, you should concentrate your efforts on fixing your code instead of building a palisade of excuses around it. Purpose, on the other hand, is not evident from the code itself, and needs to be specified explicitly. Purpose is also less likely to change over time, so the chance of finding out-of-date comments (yet another pet hate of mine) is reduced too.

Only code that not only looks like doing what you want but actually serves the same purpose too should be reused. No matter how tempting the functional similarities, it should be avoided. Make a copy and modify it if that makes you any happier, but since typing the code is probably the least time consuming part of development, it’s rather pointless. I know this sounds like stating the bleeding obvious, but my experiences suggest it isn’t.

Having said that, it’s not always easy to tell purpose and behaviour apart. And when you spend several years at school learning that natural phenomena don’t exhibit a purpose, it’s even harder. But this doesn’t change the overall picture: if you can’t reliably establish the purpose of a piece of code, don’t reuse it. It’ll end in tears. Don’t say you haven’t been warned.

There’s no punchline to this one. There’s no tool either* that would aid in documenting purpose and searching or managing reusable code bits and I don’t even know exactly what such a tool would look like but I know there bloody well should be one.


*At least none that I know of and would work on Java code. I know literate programming has a partial answer to some of these problems, but I find the idea of writing what’s when all’s said and done invalid code unacceptable in the age of modern IDEs.

Lol and behold

May 1, 2010

Science is weird and wonderful.

Science made us realise that if you ate five portions of fruit and veg a day,  it reduces the risk of cancer by 50%. And science told us that actually it’s just 2.5%. Well, I guess it’s the taking part that matters.

The wild swing is hardly a surprise though; people are notoriously squishy and wobbly, and not only literally but also as subjects of scientific examination  It isn’t fair to medical scientists. Astronomers can be much more laid back about their subjects, the object that appears to move four times faster than light in the galaxy M82 isn’t going to kick up a fuss when astronomers describe it with the words “We don’t know what it is”. They can give their papers titles more befitting to a Victorian horror story, like “The shocking size of Comet McNaught”. They can even propose that a dwarf planet be called Rupert. (Okay, they haven’t done that last one, but they could’ve done it.)

But undoubtedly environmental scientists have it the worst. Not only do they have to cope with immense political pressure and public expectations, their subject appears to be simple to everyone but them. I mean, how hard can it be to watch the thermometers, then plot a line between the data points? They also have to be very serious about their job, they can’t even reduce the pressure with a joke. The death of our beloved planet is no laughing matter after all.

No wonder it came as a shock to them when they found out.that the thawing of nitrous oxide deposits is faster than previously estimated. So the bad news is that we’re all gonna die, but at least we’ll be able to see the funny side of it.