Development or Customisation? (no they aren’t the same)

Every day we face conversations around customisation and configuration.

“We have a rule, no more than 10% customisation”. My first question is, “How do you define customisation?” There’s often a little hesitation or awkwardness as it’s a question not usually asked.

The most common, simple, lazy, and incorrect answer is “code”. Saying that when you use code you are customising the application is simply put, the wrong answer. If your application has a way for managing tasks, but you decide to build a new version of tasks, but you haven’t used any code at all, only point and click configuration, you have customised the application, you have taking something it already does and decided you want to do it a different way. Similarly, if your application has no way of creating tasks or anything similar, and you decide to build it using code, you haven’t customised it, you’ve just extended it.

These are very different and very important. In that example when I used configuration, I was customising, and when I was using code, I wasn’t. Customisation is when you take something that has already been built, and decide to rebuild it or fundamentally change it for your own use. And also to be very clear, there is nothing wrong with this as long as you have a valuable reason for why you’re doing it. There are absolutely times required to customise, and this is completely ok, this is when the application just does not do what you need it to do, which is why applications allow you to customise in the first place, we aren’t all the same, best practice is contextual, you need the application to do what’s valuable for you. You have however made a mistake when you customise purely because of convenience. It’s changing the entire architecture of something to avoid one click, although, even this example could be valuable because maybe you’re doing this click 1000 times a day?

The second issue I have with “we have a rule, no more than 10% customisation”, is the 10% part. Firstly, how do you even measure this? Let’s say an application has 5 functions with a million lines of code, but then I replace one of those functions with something I’ve built but it’s only 10 lines of code. Is that 20% customisation or 0.01% customisation? People are choosing applications today based on the fact that you can customise, so why are we so afraid of it?

The correct way of phrasing this is, “we only customise if there is long term value in doing so, and that customisation can’t be avoided without significant impact”. Wrong customisation is when the CFO is used to seeing a pie chart, but our application shows it as a bar chart, and we customise that to make them happy.

These decisions should also be made slowly. What’s the rush? We are making a decision now that impacts the next 5 years and beyond. The only way to make this is to show how both options operate and measure the impacts of each. It can’t just live in a design document, you need to make it tangible, let people see, play, feel each approach.

The next time you hear the term customisation vs config, first chat about what it means. There is plenty of customisation using only config, and plenty of code that isn’t.