Liam O'Donnellpart designer. part developer. all creative

I went to an interesting talk on Enterprise Integration Patterns at SkillsMatter the other day. Though aimed primarily at Java developers, there was not a scrap of code and the concepts discussed could apply to development in almost any language.

The focus of the talk was: good, simple code design versus just using lots of clever inheritance to create complex-looking, unmaintainable frameworks. Common sense really – it’s the kind of ‘form over function’ approach that we’re all too aware of plaguing the creative world that applies to programmers too. I’m sure many developers (especially us contractors) have personal experience of this. Be it having to use over-complicated web services, where three lines of PHP would do the trick. Or being forced to base a project on some client’s ailing framework, written in the dark ages, with little or no support.

However, it’s the reality of having to integrate with a host of unknown systems that keeps the job interesting, I suppose. It does mean, however, that the Holy Grail of code reuse (even across similar projects) doesn’t often happen the way we’d like. How many times have I heard “it’s OK, this half-finished project is all in classes, so it should be easy to repurpose”?

With such specific requirements to any individual project, some classes and knowledge can be reused, but the more complex the program structure, the more difficult it is to grasp mentally. Also, design patterns mean exactly that: patterns. Not: “this is the way we do every project”, but general approaches you learn from experience are more apt for a given task.