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.

Advertisements

Tags: , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: