Some Amusing Industry AntiPatterns
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.