Антипаттерны организации и управления:

• Аналитический паралич (Analysis paralysis): Неоправданное внимание и затраты времени/ресурсов на стадию анализа.
• Дойная корова (Cash cow): Прибыльный и успешный продукт, высокая прибыль от которого зачастую приводит к чрезмерной расслабленности в разработке новых версий продукта или новых продуктов.
• Разработка комитетом (Design by committee): Результат вклада в разработку многих участников, но отсутствие единого видения.
• Эскалация обязательств (Escalation of commitment): Неспособность отказаться от решения даже когда доказана его ошибочность.
• Драконовские меры (Management by perkele): Авторитарный стиль управления, отвергающий инакомыслие.
• Moral hazard: Отделение человека, принимающего решения, от последствий этих решений.
• Управление грибами (Mushroom management): Стиль управления, при котором работникам предоставляется минимум информации и эта информация искажается (управлять грибами - содержть в темноте и прикрмливать навозом) .
• Управление основанное на числах (Management by numbers): Уделение избыточного внимания численным критериям управления, когда они неважны или стоимость их получения слишком высока
• Дымоход (Stovepipe): Организационная структура, при которой потоки информации циркулируют преимущественно вверх-вниз, но не горизонтально, между подразделениями.
• Замкнутость на продавце (Vendor lock-in): Чрезмерная зависимость системы от внешней компоненты.
• Сваливание расходов (Cost migration): Перенос расходов на проект к уязвимому отделу или бизнес-партнёру.
• Путь камикадзе (Death march): Все знают, что проект обречён, кроме главы, вплоть до "дня X". Также применяется для стиля руководства, когда сотрудники вынуждаются к сверхурочной работе для достижения нереальных сроков.
• Расползание рамок (Scope creep): Дозволение рамкам проекта расти без должного контроля.
• Groupthink: Никто не хочет выдвигать идеи, противоречащие комфортному консенсусу.
• Дым и зеркала (Smoke and mirrors): Демонстрация заказчику заранее заготовленных "обманок" вместо рабочей функциональности.
• Раздувание ПО (Software bloat), Функции для галочки: Каждая следующая версия продукта требует всё больше системных ресурсов без явной выгоды для пользователя.
• Ползущий улучшизм (Creeping featurism): Добавление новых улучшений в ущерб качеству системы.
• Продолжительное устаревание (Continuous obsolescence): Выделение непропорционально больших усилий портированию системы в новые окружения.
• Bystander apathy: Дизайн или требования неверны, но те, кто это знают, ничего не предпринимают по этому поводу, т.к. для этого необходимо вовлечение большего числа людей.
• Tester Driven Development: Новые требования к продукту возникают из отчётов об ошибках.
• Я тебе это говорил (I told you so): Когда игнорируется предупреждение эксперта, являющееся оправданным
• Единственный знающий человек (Single head of knowledge): ЕЗЧ (SHOK) применим в том случае, когда единственная личность во всей организации контролирует жизненно-важную область ноу-хау или информации о внутренностях системы.
• Рыцарь на белом коне (Knight in shining armor): РНБК (KISA) происходит тогда, когда личность, которая не совершает ошибок, появляется на сцене и пытается починить всё, без сообщений о том, какие изменения он/она сделал/сделает и почему.
• Gold plating: Работа над проектом после момента, когда уже усилия перестают приносить прибыль или создавать добавочную стоимость.

• Большой комок грязи (Big ball of mud), Проблема йо-йо (Yo-yo problem), Спагетти-код (Spaghetti code): Структура системы отсутствует или трудно поддаётся пониманию.
• Бензиновая фабрика (Gas factory), Ненужная сложность (Accidental complexity), Inner-platform effect, Раздувание интерфейса (Interface bloat): Неоправданное усложнение дизайна системы, излишняя гибкость или универсальность.
• Инверсия абстракции (Abstraction inversion): Не предоставление реализованных функций, необходимых пользователям, что вынуждает их реализовывать эти функции заново с помощью функций более высокого уровня.
• Database-as-IPC: Использование базы данных для обмена соосбщениями между процессами там, где можно использовать более легковесные способы.
• Затычка на ввод данных (Input kludge): Отсутствие коректной обработки возможного неверного ввода.
• Магическая кнопка (Magic pushbutton): Написание бизнес-логики в коде пользовательского интерфейса (например в обработчике события нажатия на кнопку).
• Гонки (Race hazard):Ошибка в определении последовательности различных порядков событий.
• Базовый класс-утилита (BaseBean): Наследование класса-утилиты вместо делегирования к нему.
• Вызов предка (Call super): Для реализации прикладной функциональности методу класса-потомка требуется в обязательном порядке вызывать те же методы класса-предка.
• Circular dependency: Ненужная прямая или непрямая взаимная зависимость между объектами или модулями.
• Блоб (Blob), Божественный объект (God object): Концентрация слишком большого количества функций в одиночной части дизайна (классе).
• Объектная клоака (Object cesspool): Повторнае использование объектов, чьё состояние не удовлетворяет (возможно неявным) условиям повторного использования.
• Паблик Морозов (Object orgy): Предоставление неоправданного доступа к внутренним свойствам объекта.
• Полтергейст (Poltergeists): Объекты, чьё единственное предназначение — передавать информацию другим объектам.
• Sequential coupling: Класс, требующий вызова его методов в строго определённом порядке.
• Действие на расстоянии (Action at a distance): Неожиданное взаимодействие между далёкими частями системы.
• Накопить и запустить (Accumulate and fire): Установка параметров подпрограмм в наборе глобальных переменных.
• Слепая вера (Blind faith): Недостаточная проверка корректности исправления ошибки или результата работы подпрограммы.
• Лодочный якорь (Boat anchor): Сохранение более не используемой части системы.
• Активное ожидание (Busy spin): Потребление ресурсов процессора во время ожидания события, обычно при помощи постоянно повторяемой проверки, вместо того, чтобы использовать систему сообщений.
• Cargo cult programming: Использование паттернов и методик без понимания причин.
• Проверка типа вместо интерфейса (Checking type instead of membership, Checking type instead of interface): Проверка того, что объект имеет специфический тип в то время, когда требуется только определённый интерфейс.
• Инерция кода (Code momentum): Сверхограничение части системы путём постоянного подразумевания её поведения в других частях системы.
• Кодирование путём исключения (Coding by exception): Добавление нового кода для поддержки каждого специального распознанного случая.
• Таинственный код (Cryptic code): Использование аббревиатур вместо мнемоничных имён.
• Error hiding: Перехват сообщения об ошибке до того, как она показывается пользователю, в следствие чего пользователь не получает сообщения об ошибке или получает бессмысленное сообщение.
• Expection handling: Использование системы исключений для реализации бизнес-логики системы.
• Жёсткое кодирование (Hard code): Внедрение предположений об окружении системы в слишком большом количестве точек её реализации
• Мягкое кодирование (Soft code): Патологическая боязнь жёсткого кодирования, приводящая к тому, что настраивается всё что угодно, при этом конфигурирование системы само по себе превращается в программирование.
• Поток лавы (Lava flow): Сохранение нежелательного (излишнего или низкокачественного) кода по причине того, что его удаление слишком дорого или будет иметь непредсказуемые последствия.
• Loop-switch sequence: Кодирование последовательности шагов с помощью цикла и оператора выбора (switch).
• Магические числа (Magic numbers): Включение чисел в алгоритмы без объяснений.
• Программирование методом копирования-вставки (Copy and paste programming): Копирование (и лёгкая модификация) существующего кода вместо создания общих решений.
• Дефакторинг (De-Factoring): Процесс уничтожения функциональности и замены её документацией.
• Золотой молоток (Golden hammer, Silver bullet):  Сильная уверенность в том, что любимое решение универсально применимо.
• Фактор невероятности (Improbability factor): Предположение о невероятности того, что сработает известная ошибка.
• Преждевременная оптимизация (Premature optimization): Оптимизация на ранних стадиях в ущерб хорошему дизайну, сопроводимости и иногда даже реальной эффективности системы.
• Programming by permutation (или "programming by accident"): Попытка достижения нужного результата путём последовательного изменения кода и проверки помогает ли это.
• Изобретение колеса (Reinventing the wheel): Разработка собственного решения вместо применения существующего.
• Изобретение квадратного колеса (Reinventing the square wheel): Создание собственного плохого решения, когда существует хорошее.
• Ад зависимостей (Dependency hell), DLL-ад (DLL hell): Проблемы с совместно испльзуемыми билиотеками по причине различий в версиях одной и той же библиотеки

Источники

1. Anti-pattern on wikipedia.org

2. Антипаттерн на wikipedia.org