There was some debate this week at the Gilb Seminar 2012 on anti-patterns, and in particular whether a project was an anti-pattern.

The subject was introduced by Clifford Shelley, who was, more broadly, proposing the idea anti-patterns are a productive and fun way of better understanding and improving software and ways of working. There wasn’t too much debate about that, but there was much debate over what should be added to the list. Some of anti-pattern candidates were most likely just personal bugbears.

There was general agreement that projects tend to be troublesome and generally fail. I know one major company that is eliminating them entirely and replacing them with a process of incremental improvement.

But can a project be considered an anti-pattern based on that? As one of our number suggested, they tend to fail because of poor implementation, and an anti-pattern should be independent of implementation.

I think projects are a convenient way of focusing activity towards a particular goal. But then projects’ detractors would say that steps towards the goal should be realised early and often, and the goal should be under continuous review anyway — both of which tend to invalidate the principle of a project.

Seeking to eliminate projects is probably no bad thing, regardless of how we categorise them.