Performance Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 553 posts at DZone. You can read more from them at their website. View Full User Profile

Products and Infinite Configurability

08.26.2013
| 4018 views |
  • submit to reddit

One of the common feature requests on the ThoughtWorks projects that I worked on was that the application we were working on should be almost infinitely configurable to cover potential future use cases.

My experience of attempting to do this was that you ended up with an extremely complicated code base and those future use cases often didn’t come to fruition.

It therefore made more sense to solve the problem at hand and then make the code more configurable if or when the need arose.

Now that I’m working on a product and associated tools I’m trying to understand whether those rules of application development apply.

One thing I think makes sense is the idea of convention over configuration, an approach that I became familiar with after working with Ruby on Rails in 2010/2011.

The phrase essentially means a developer only needs to specify unconventional aspects of the application.

Even if we do this I wonder if it goes far enough. The more things we make configurable, the more complexity we add and the more opportunity for people to create themselves problems through misconfiguration.

Perhaps we should only make a few things configurable and have our application work out appropriate values for everything else.

There are a reasonable number of people using a product who don’t have much interest in learning how to configure it. They just want to use it to solve a problem they have without having to think too much.

Although I haven’t used it I’m told that Azul’s Zing JVM takes the minimal configuration approach by only requiring you to specify one parameter – the heap size – and it handles everything else for you.

Of course I’m still new to this so perhaps it still does make sense to default most things but allow power users full control in case their use case differs from the average one that the defaults were created for.

I’d be interested in hearing the opinions of people more experienced in this arena of which there are undoubtably many.



Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)