Anti Patterns

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.

    Leave a Reply

    Fill in your details below or click an icon to log in: Logo

    You are commenting using your account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )

    Connecting to %s