How much should you customise?

Joel Spolsky has started a series on the making of FogBugz 4.0, initially talking about the requests of customers, and how (and when) this should translate into changes in your software.

The request for customisation is a question most of us involved in coding will face at some time or another. Even if your system has only a single “client”, do you really want to bend it and stretch it in such a way that it’s no longer future-proof?

In most cases, if you can avoid it, I suspect the answer is no. You want to keep it generic. Because as sure as night follows day, the pendulum of your customer’s direction will swing back the other way, and you’ll end up having to build yourself out of that hole they urged you to dig.

For example, in my work on the earlier version of what has become eVision’s Message Exchange, at times we have needed to generate and transmit messages quite different from the established standard types we were already spitting out. Natively we could handle XML and flat file (delimited or fixed-length) output files, but what if we wanted to add Zip compression on top of that? Or what about some other weird and wonderful thing?

In the case of Zip, we built that into the software using the very handy InfoZip DLL. But for others that appeared to be so specialised that we didn’t want to lumber the code with them forever more, we built on a “post-process” step, which allowed the output file to be subject to an external process before it was transmitted.

This kind of generic hook into the software has opened up numerous possibilities. So when the business dudes came along and asked for a file to be generated that did an additional lookup off a reference table, we were able to write that step as a separate process. It all works rather well.

So in some cases, the answer to customisation is interopability. Rather than bend and stretch your masterpiece into something it shouldn’t be, you put the hooks in so you or somebody else can do the bending and stretching over in a separate corner.

Your code can stay clean and future-proof, and everybody’s happy.

If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.