Agile 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

Ultimate configurability

08.26.2010
| 1634 views |
  • submit to reddit

In Continuous Delivery the authors talk about the danger of ultimate configurability…

Configurable software is not always the cheaper solution it appears to be. It’s almost always better to focus on delivering the high-value functionality with little configuration and then add configuration options later when necessary


…and from my experience when you take this over configurability to its logical conclusion you end up developing a framework that can hopefully just be 'configured' for any number of 'front ends'.


This seems to be quite a common thing to do across organisations and typically the decision about what needs to go into the framework is made before there's been much/any development on the applications which will make use of said framework.

In addition the framework is typically built by a different team to the ones who are going to be working on the applications which make use of it.

As a result it's very difficult for that team to know exactly what they should be building so we'll typically end up with something that is overcomplicated for the situations it's actually required for.

In my mind the problem that we create for ourselves is the same as when we try to write a massive piece of code all in one go instead of driving it out through examples.

We try to imagine how the code might be used rather than knowing how it will actually be used.

Udi Dahan talks about favouring use over reuse and I think this is the ultimate example of not doing that.

A more effective approach would be to develop those websites/front ends individually and then let the shared 'framework' evolve from there.

That way we know that we've extracted some shared ideas because we needed to rather than because we thought we might need to.

Even then we need to be careful about what we share between applications because often it might be best to just accept a bit of duplication to avoid the implicit dependency created between teams.


References
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.)