Create positive patterns to prevent or cure the effects of anti-patterns that make a project rot.

Tuesday 1 April, 14:30

workshop -    150 minutes

Matt Stephenson
Stephen Hutchinson

Abstract

Jim Coplien describes an anti-pattern as “something that looks like a good idea, but which backfires badly when applied”.

So, how do we stop anti-patterns from affecting our projects? The glib answer is often, “just stop doing them!”. We feel this isn’t good enough for two reasons.

Firstly, the most successful way to break the habit of one behaviour is to introduce a replacement behaviour that is better, in the form of an alternative positive pattern.

Secondly, there may be cases where it is not possible to prevent the anti-pattern from being employed and we need a mechanism to deal with the consequences, described as remedial positive patterns.

In either case, it is vital that the new solution continues to satisfy all the forces that caused the anti-pattern to be used in the first place.

An example of this phenomenon can be seen at www.c2.com/cgi/wiki?BearTrap?? where the Stone Soup pattern is used to counter the negative effects of the Bear Trap.

At OT2002, Steve Freeman and Frank Westphal ran a session called “Project Rot: How to spot it and how to stop it”. That session produced an understanding of the symptoms to look out for that indicate a project turning rotten, and generated some suggestions for remedial action.

Our session will take this work a step further and attempt to formalise a pattern language for combating project rot.

Audience

Delegates do not need to have attended the Project Rot session at OT2002.

Benefits

• Recognition of the anti-patterns that are often applied to projects that result in Project Rot.

• Take away a pattern language that can be utilised on projects to help prevent them from turning rotten or cure the early signs of Project Rot.

Materials

• Anti-patterns relating to Project Rot.
• Templates for documenting positive patterns.

Matt Stephenson

I've earned a living from technology since 1993. I've been a developer, designer, architect, team leader, project manager and outsourced relationship manager.

In November 2007 I moved to Moneysupermarket.com as Solution Architect for Travelsupermarket. Since joining Moneysupemarket I have changed role and I'm now Head of Business Engagement - responsible for the relationship between IT and the business and delivery of the IT Plan.

I co-led a session at OT2001 called "Extreme Programming in the Real World" where we considered the difficulties that arise when you try to introduce XP to a large organisation that has a more traditional approach to IT.

At OT2002 I co-presented an Introduction to XP called "Extreme Programming - The Software Generation Game". It was designed in response to feedback that most of the XP sessions at OT2001 assumed prior knowledge of the method.

At OT2003 I co-presented "Fighting Fire with Fire - A Pattern Language for Rotten Projects". This workshop set out to begin documenting a Pattern Language to prevent software development projects from going bad.

At OT2004 I co-presented "A picture paints a thousand words... Or does it?" which considered the differences between good and bad architecture and design documentation. It discussed the ways in which we can produce or influence the production of better documentation.

Stephen Hutchinson

I was chief designer of the RSA direct-sales motor insurance system. This is written in Smalltalk, supports 1000 telesales users and is also on the Web. I'm a big fan of Smalltalk and eXtreme Programming, and have promoted XP in the big bad world of Corporate IT - with some success.

I am now working as Solution Architect on RSA's PCI DSS compliance project.

I am married with three children and live in the depths of rural Cheshire. I play the saxophone with Wychcraft Big Band and enjoy wearing silly hats.