Peter principle: Continually promoting otherwise well-performing employees up to their level of incompetence, where they remain indefinitely

Seagull management: Management in which managers only interact with employees when a problem arises, when they "fly in, make a lot of noise, dump on everyone, do not solve problem, then fly out"

Stovepipe or Silos: An organizational structure of isolated or semi-isolated teams, in which too many communications take place up and down the hierarchy, rather than directly with other teams across the organization

Typecasting: Locking successful employees into overly safe, narrowly defined, predictable roles based on their past successes rather than their potential

Vendor lock-in: Making a system excessively dependent on an externally supplied component

Death march: A project whose staff, while expecting it to fail, are compelled to continue, often with much overwork, by management which is in denial

Ninety-ninety rule: Tendency to underestimate the amount of time to complete a project when it is "nearly done"

Overengineering: Spending resources making a project more robust and complex than is needed

Scope creep: Uncontrolled changes or continuous growth in a project’s scope, or adding new features to the project after the original requirements have been drafted and accepted (also known as requirement creep and feature creep)

Smoke and mirrors: Demonstrating unimplemented functions as if they were already implemented

Brooks' law: Adding more resources to a project to increase velocity, when the project is already slowed down by coordination overhead.

Abstraction inversion: Not exposing implemented functionality required by callers of a function/method/constructor, so that the calling code awkwardly re-implements the same functionality in terms of those calls

Anemic domain model: The use of the domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places). Martin Fowler considers this to be an anti-pattern, but some disagree that it is always an anti-pattern.[4]

Error hiding: Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message. This anti-pattern is also named Diaper Pattern. 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

^Koenig, Andrew (March–April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming. 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). The patterns handbook: techniques, strategies, and applications. Cambridge, U.K.: Cambridge University Press. p. 387. ISBN0-521-64818-1. "An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution, but isn't one."

^"Revenge of the Nerds". In the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough— often that I'm generating by hand the expansions of some macro that I need to write.