willCode4Beer

Patterns in Development

I've been to a few workshops now where the common theme is "patterns" in development.

The thing is, they way the word is being used, they are really describing templates. The big usage is for transformations and dealing with common things. While it looks like a big time saver for architecture and design tasks, I don't feel so positive about using it with source code. My first thought, and confirmed with later discussions with other participants, is that the result would be "engineering code duplication".

I understand the concepts of trying to encapsulate, for reuse, expertise. But, I think it might be better for those with the expertise to create configurable libraries to simplify complex tasks. Then again, I'm one of those wacky, make an API instead of duplicating code kind of guys.

On the area of creating new projects, they probably do have a point. Things like building hibernate mapping files, dao's, Spring configurations, etc... are probably good to be simply generated from a model. As long as everybody realizes that the generated files are just a starting point, they will need to be changed. The fact that they have to be changed takes away from the concept of encapsulating expertise.

This brings up another point. Do we really want to encapsulate expertise? If we do it, where do the future experts come from? How about templates that get junior developers started? Then they can be brought into best practices gradually until they can handle things on their own and eventually move into the role of expert. This should be a change from encapsulated expertise to transparent expertise.

posted by willCode4Beer @ 8:12 PM