“And accordingly he praised the stuff he could not see, and declared that he was delighted with both colors and patterns” – Hans Christian Andersen, The Emperor’s New Clothes
“I look for patterns that nobody else does. Like I noticed that my face looks like a tablecloth. Especially when I have food all over it.” – Jarod Kintz, This Book is Not FOR SALE
Patterns have been used in software engineering at least since the 1990s as recurring solutions to common problems. Wikipedia describes an anti-pattern as “a common response to a recurring problem that is usually ineffective and risks being highly counterproductive”, e.g analysis paralysis, cargo cult programming, death march, groupthink and vendor lock-in.
Recent evidence suggests that some common ICT industry patterns are turning out to be anti-patterns. Examples are wide-ranging, even including an Anti-Pattern for Anti-Patterns in Software Development Organizations:
The May/June 2015 issue of CrossTalk Magazine refers to the pattern/anti-pattern issue in the article Enough Software Processes, Let’s Do Patterns! The author notes “This paper explains common mistakes many organizations have made in the past when implementing defined processes with a goal of improving software practitioner performance. The paper suggests a more effective approach to improvement is to focus on patterns where software practitioners need help in making better decisions.”
The Jan/Feb 2015 issue of CrossTalk Magazine has an article, Training Software Project Managers which comes at the anti-pattern issue from a different angle. One section of the article describes A Few Misconceptions Seen as Self-Evident Truths by Many Software Project Managers. The author also acknowledges that portions of the article contain excerpts from his Kindle eBook, “Managing Software Projects: On the Edge of Chaos, From Antipatterns to Success”
An Apr 04, 2015 InfoQ report from the DevOps Days Ljubljana 2015 event describes the presentation by Oliver Hankeln, DevOps and Agile consultant, on Anti-patterns for Handling Failure.“Hiding mistakes due to a predominant blame culture prevents organizations from effectively learning from failures and becoming more resilient. Hankeln breaks this down into four recurring anti-patterns: hiding mistakes, engaging in blame game, the arc of escalation and cowardice. He then suggests corrective actions for each of them.”
In a 2 Apr 2015 Microsoft Press Guest article: Kanban anti-patterns, Kim Spilker notes “ if you think you know Kanban already and aren’t seeing the benefits of continuous value delivery, simple planning and estimation, tight customer connection, inherent quality guarantees, focused scope, and reduced meeting times, then you’re probably falling into one of the seven Kanban anti-patterns I describe below.” Kim describes the 7 anti-patterns, shows how to correct them and provides a general checklist of actions to take that correct Kanban anti-patterns.
The Second Workshop on Patterns Promotion and Anti-patterns Prevention (PPAP) 2015 was co-located with the 22nd IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER’2015) in Montreal in March. Workshops included “Anti-Pattern for Anti-Patterns in Software Development Organizations”.
The authors describe how software development organizations unwittingly adopt anti-patterns as “Best Practices”, then are faced with “adding a “patch” to correct the observed problem(s). This is what we call an anti-pattern for anti-patterns.”