Anti Patterns

• Accidental complexity: Introducing unnecessary complexity into a solution
• Action at a distance: Unexpected interaction between widely separated parts of a system
• Blind faith: Lack of checking of (a) the correctness of a bug fix or (b) the result of a subroutine
• Boat anchor: Retaining a part of a system that no longer has any use
• Busy waiting: Consuming CPU while waiting for something to happen, usually by repeated checking instead of messaging
• Caching failure: Forgetting to reset an error flag when an error has been corrected
• Cargo cult programming: Using patterns and methods without understanding why
• Coding by exception: Adding new code to handle each special case as it is recognized
• Design pattern: The use of patterns has itself been called an anti-pattern, a sign that a system is not employing enough abstraction.
• Error hiding: Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message. Also can refer to erasing the Stack trace during exception handling, which can hamper debugging.
• Hard code: Embedding assumptions about the environment of a system in its implementation
• Indadvertent Query Execution: This is the naive use of Object Relational Mapping software such as Entity Framework that results in multiple database queries being run when only one database query is required.

For example the following LINQ to Entities code:

IQueryable myCusts = from c in contacts select c;

myCusts.ToList(); //forces the query to execute
myCusts.Count(); //forces the query to execute again
foreach(var c in myCusts)
{/* do something */} //forces the query to execute again
myDataGrid.DataSource; //forces the query to execute again

Instead of this approach, assign the result of your first query to a variable so that all future operations can be performed based on the data in memory:

var query = from c in context.Customers select c;

var customers = query.ToList(); //executed via database query
var myCount = customers.Count(); //executed based on the query results which is stored in memory
var myFirstCustomer = customer.First(); //executed based on the query result which is stored in memory

• Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences.
  Mike Hadlow has written a great blog post on this topic.

• Loop-switch sequence: Encoding a set of sequential steps using a switch within a loop statement
• Magic numbers: Including unexplained numbers in algorithms
• Magic strings: Including literal strings in code, for comparisons, as event types etc.
• Promise anti-patterns: A whole set of anti-patterns for misuse of the JavaScript promise pattern
• Repeating yourself: Writing code which contains repetitive patterns and substrings over again; avoid with once and only once (abstraction principle)
• Shotgun surgery: Developer adds features to an application codebase which span a multiplicity of implementors or implementations in a single change.
  Soft code: Storing business logic in configuration files rather than source code
• Spaghetti code: Programs whose structure is barely comprehensible, especially because of misuse of code structures

• Lasagna code: Programs whose structure consists of too many layers

Account Management Anti-Patterns

Storing passwords in plain text. See Plain Text Offenders for many examples.

Storing passwords base 64 encoded (no better than plain text)

Storing passwords with symmetric encryption that can be decrypted

Storing passwords in hashed form but with no salt

Limiting characters in passwords (either disallowing specific characters or limiting the length of the password)

Emailing credentials on account creation (these are plain text)

Password change facility without setting XFO header (allows a clickjacking attack)

Account enumeration (telling users whether the username or email they entered exists in your database)

Using auth cookies with a long expiration, or no expiration

Allowing password change without re-authentication

SQL Data Generation Anti-patterns

Manual creation
Hand written scripts
Pulling a copy of production data
These are described by Troy Hunt in SQL data generation

Lean UX Anti-Patterns

The following is a list of cultural or process anti-patterns (not code). This is a summary of the presentation that can be found in full here:
Lean UX Anti-Patterns
Bill Scott’s FrontEnd Masters Workshop on Pluralsight

1. Genius Designer
All design emanates from an uber designer.
Team doesn’t collaboratively participate in design/ideation.

2. Tribal group
When a team is very small members are forced to work across disciplines.
As soon as team gets bigger, tribes reform around disciplines
Collaboration stops

3. Newcomer
Lean teams will form shared understanding.
However, when new team member joins we assume this hard earned understanding will just happen.

4. Addicted
Teams will often make a good start by trying out new behaviours and seemingly leave old behaviours behind.
Beware! Old habits will creep back in.

5. Naysayer
With collaboration so important it is key to believe in the process to create great products.
A single naysayer can bring the team down in an instant.

6. Visitor
Input from outside the team is essential.
However, watch out people cycling in & out of the team can cause the same disruption that the newcomer
anti-pattern causes.

7. Magic Tool
Design & Prototyping tools can accelerate ideation and design.
However, be careful, tools that empower prototyping can enable designers to work in isolation.

8. Going Dark
When a developer, product manager, or designer goes dark for more than a day (or two) the team is losing valuable collaboration.

9. Change of Cadence
Change of cadence is actually a good and normal happening.
However whenever the rhythm changes it can bring productivity down.

10. Too many cooks
The work needs to be divided up among different types of cooks
(Chef de cuisine, Sous chef, Chef de partie)

11. Not enough pizza
When a team suddenly scales up in size
the team is in danger of losing cadence, shared understanding and focus

12. Tower of Babel
Shared understanding is key to lean UX.
However, it is easy to assume too quickly that team members are speaking the same language

13. You Got Mail
Teams can revert to email over collaboration
Also geographically distributed teams can fall into delivery by email versus collaboration

14. Inmates run the asylum
From Alan Cooper’s classic book
When engineers drive design the inmates are running the asylum

15. Perfectionist
Not embracing the challenge of the unknown, the perfectionist will not share their work till it is perfect.
Easy for designers to fall into this trap.

16. Weakest Link
Team members who aren’t up to the challenge of close proximity & transparency can cause a team to stumble

17. The Wall
Walls between teams can happen when
– we allow tribes to form
– we see the other teams as separate delivery factories
– geo-distributed teams

18. Tangled Up Technology
Unless the technology stack is built to have a clear separation from experience & services
the lean team cannot make rapid progress.
Watch out when dev teams care too much about the specific version of the UI.