The Bad Code Offsets project is an attempt to get programmers to put money into open source software. We may not be able to change the bad code we have written. Instead we can buy an offset that goes towards creating more good code.

Bad code lives on well past the time we inflicted those bad lines into the global code base. Applications continue to live their lives serving businesses, consumers and the global community at large. Bad code weakens the utility delivered by these applications causing business loss, user dissatisfaction, accidents, disasters and, in general, sucks limited resources towards responding to the after effects of bad code rather than toward the common good.

They have just made a $500 grant to the GPSd project, which aims to shield developers from the idiosyncracies of integrating each GPS device available.

How often do you use open source software. How often have you contributed, either by submitting code or donating money? My gut feeling is that at least 95% of developers haven't done either. The 10 USD I donated will be going to the Apache software foundation. The apache webserver has been at the base of nearly every project I've worked on and will be for a long time to come.

Glue is what holds your application together. Code needs to talk to databases, Javascript is calling your PHP functions using Ajax. When two systems, or different parts of the same system need to talk to each other, you end up with glue. It (hopefully) doesn't have any business logic. It's used or copied by at least a few different parts of your system, perhaps even in different projects in the same organisation.

Glue code holds things together. The only problem is that glue is not your application. Unless you're developing a framework, operating system or perhaps something that needs plugins, glue is not your strength. There are always exceptions but if you are writing glue, especially the same glue for the 3rd or 4th time, then you're not directly working on the application you are building.

Having said that, your project won't survive without glue. So how do you keep everything together?

• Recognise glue. The first step is to understand that you are now writing glue code and not working on business requirements. For example, say you are writing a script to process files that are uploaded to your server. Discovering the files is glue, the processing of then is specific to your application.
• Standardise across your organisation. Glue may start out as a one off but as time moves on it will become apparent which pieces are worth time improving and which aren't.
• Make it as simple to use as possible. It will need to be understood by a larger group of developers than your other code. Put that extra time into documentation and code beautification.
• Make it as robust as possible. You don't want this getting in the way of your 'actual' work.
• Use 3rd party glue. Someone has nearly always been before you. Wiring your PHP and JS together with AJAX? It's been done. Creating a DB access class? Been there, done that. If you think you can do better your probably wrong. You may write better code, but you probably won't document or test it as thoroughly as an open source project has already been.

In conclusion, you want to keep glue simple and straight forward. Recognise what is and isn't glue in your application. Share the glue you have with every one in your team, and if your brave, the outside world.

The idea of glue is described in Eric Raymond's excellent book The art of unix programming.