Sermon on the mount(8).2

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.

Sermon on the mount(8)

Now I’m gonna preach about software development.

What qualifications have I got to allow me to do this? Well, to start with, I’ve been working as a software developer for some time. And …er, that’s all. So basically I’m going to talk out of my arse, like everyone else, except that I admit it.

There was a story in the papers today about a Polish bloke who burgled companies by posting himself in a large parcel to their addresses, nicking stuff during the night, then posting himself back to his home address. He was caught eventually, but it’s a brilliant idea nevertheless.

And that brings me neatly to the subject of today’s rant: thinking outside the box.

It’s been all the rage for some time in corporate circles and it does my head in. They encourage everyone to think outside the box all the time, completely ignoring the sad truth that most people are thoroughly unable to think, be that inside or outside that box.

Of course I’m not suggesting that nobody should do it, there’s certainly need for people who can pretend that the box isn’t there and come up with ideas the likes of which nobody else had thought before. But more often than not it isn’t what you need at all, not unless  you have to design and create a completely groundbreaking stuff, which you very rarely have to.

It would be much more useful instead if people learned to recognise a box and to be able to figure out why it is there in the first place.

If nothing else, you might avoid being robbed.