Oops. Looks like the acute accent on the permalink broke things on some browsers. I've reverted it to something more illiterate - apologies if you therefore see this article twice! Irony, thy name is GeekLondon...

As a developer, it's always tempting to fix someone else's broken code/architecture/schema. Rarely a good idea. This is particularly true if you are working in a commercial environment.

This is not a new point, and as usual with business common sense, Joel Spolsky has made the point already in one of his excellent business-meets-technical essays.

However, I do believe that for personal projects, or projects that don't have a significant time or financial budget (open source, for example), where ongoing maintainability or aesthetic values are more important to the participants than the time constraints, that the "If it ain't broke, don't fix it" cliché doesn't really hold.

Ever in search of a more accurate aphorism, I found myself mouthing this one today. For once it doesn't seem to be a meme that I've channelled from some other obscure corner of the internet, so here it is for posterity:

You might as well keep the worms in the can unless they're paying you to make spaghetti.

The context of this was mooting the replacement of a possibly half-baked, but apparently working, block of custom primary key generation logic. This is in an application that's using Hibernate for it's ORM (Database Persistence) tool.

It may well be that there are bugs in this dodgy looking logic. And I know that Hibernate's key generation logic is rock solid. But still. Until we encounter something that's definitely broken, we'll keep the lid on it. When it's proven itself broken, however, I'll let you know what horrors I find therein.

But until we know for a fact that it's broken, the client's paying for ravioli and we can't waste time "tidying" the functional bits.