Tech Blog – Jonathan Holloway

It is always exciting to have your work noticed, and respected, by other designers…so today Oogly are happy to say we are featured on David Pache’s article “100 Brands of Interest“.

As David comments, “It can be the easiest thing to create a logo for a client but when it comes to assessing what style of identity can best represent yourself or your business, this is a different matter altogether. It is tempting to use your own brand as a showcase of all your best techniques and ideas but this must be balanced with modesty and professionalism to gain the correct tone for your business image.”

Check out the full article (including our logo) here: http://www.dache.ch/dache/comments/100_Brands_of_Interest_II/

Back last year I carried out some developer interviews for my thesis at a company in the UK. Part of the interviews looked at anti-patterns that developers thought were important in the workplace. A number of these related back to the “Anti-patterns: Refactoring Software, Architecture and Projects in Crisis” book by Raphael Malveau et al… but a number of them we talked about were somewhat interesting (if only amusingly by name). What they described were issues we had faced during development with software, people and systems. They were not documented in any real depth, but a brief summary follows:

Inappropriate Use Of Patterns – Overuse of patterns or misunderstanding of patterns
Pattern Of The Week,Using a pattern for the sake of using that pattern

Tier Leakage (Cross Cutting Code) – “Using objects from one tier in another, i.e. presentation tier objects used in the integration tier”.

The Upstart – A developer who kicks up a stink about poor code, but does the same thing himself.”

Cowboy Coding/Non Learner – A person who does not want to learn about good principles or practices. They just want to get the job done quickly and ride off into the sunset.

Data In Session – Putting data into a HTTP session haphazardly.

Stick In The Mud – When someone is continually obstructive and prevents others from making progress possible because of their position of authority.

Square Peg Round Hole – Using a pattern or principle where it does not fit or causes a great deal of unnecessary complexity.

Inappropriate Reuse – When using a framework or tool is overkill and simple code could have sufficed instead.

Job Consolidation – “Consolidation of a developers’ position through the production of unreadable, unnecessarily complex code.”

Firefighting – “Continually bug fixing a system that is poorly designed, incredibly brittle with little testing in place.”

Overengineering – “A bit like YAGNI, trying to cater for improbable scenarios.”

Continual Patchwork – Continually patching or adding new features to a system when it really should be re-architected.

Hardcode Central – “Hard coding business rules that need to change often e.g. resource locations (databases, email servers etc…).”

Kerplunk – “A small change to the system breaks many things, this is inherent within brittle, poorly architected systems.”

Too Many Cooks – Having too many technical architects/leads who cannot agree on an approach to a problem.

Last Person To Leave – Blaming the last person to leave for bugs or poorly written code. A type of blamestorming.

I’ve been looking into design pattern relationships until recently and didn’t realise that there has been work done in this area in the past. I find it awkward sometimes to understand how patterns relate to other patterns and which ones should be used in certain scenarios. Judging by the community I guess I’m not on my own. I recently found out that there are various classifications of patterns, not just the arrangement of patterns laid out originally by the Gang Of Four (which I don’t find that useful to be honest) in terms of their scope and purpose:

1. Zimmer (1995) suggested a set of horizontal layers to divide the patterns and proposes some new patterns which encompass sets of patterns. An example of this is the Objectifier pattern which encompasses the Strategy, Builder, Command and Visitor patterns. In order to relate the patterns Zimmer proposes a set of relations (X uses Y in solution, X is similar to Y, X can be combined with Y). This provides a new way of working with patterns since a developer can find out which patterns can be used together and which patterns achieve the same goal.

2. Noble (1998) discussed three new primary relationships for patterns, a pattern uses, refines and conflicts with another pattern. He also describes a series of secondary relationships with a pattern being a variant of another pattern, two patterns being similar or two patterns combining to solve a problem. Noble also describes sequences of elaboration which refers to a sequence of patterns beginning with small simple patterns building up into large scale architectural patterns.

3. Tichy (1998) looked at categorizing a large number of software patterns from various sources based on their purpose. The patterns selected were general purpose patterns, i.e. patterns that can be used in many different systems irrespective of their domain. They proposed a number of different categories to contain the patterns based on the problem they solved. Some of these included decoupling, state handling, control, concurrency and distribution.

There are others, people may be familiar with the J2EE pattern blueprints that describe how each of the J2EE patterns relate to each other:

http://java.sun.com/blueprints/patterns/index.html

This is kind of interesting because it provides a big picture for us to focus on, a top level hierarchy of patterns and how they are arranged from the enterprise down.

Also one more note, most people think of patterns as being the Gang Of Four design patterns but there are loads of other pattern types as well:

Antipatterns [Brown98];
Enterprise Architecture Patterns [Fowler02];
Elementary Patterns [Wallingford98];
Concurrency Patterns [Schmidt06];
Analysis Patterns [Fowler96];
Micropatterns [Gil95];
Re-engineering Patterns;
Process Patterns

etc… etc…