Improved version

In June 2023 I published the article «Worst Development and Architecture Practices» in the corporate blog of Gazprombank on Habr.

Now I offer you a revised and expanded version of that article. Here's what changed:

  1. Full text on my own site — the article no longer depends on an external platform and reads entirely here, in a navigation-friendly form.
  2. Each antipattern in its own section — every section has its own page, table of contents and breadcrumbs, with a "back to overview" link.
  3. Detailed code examples — each antipattern now has concrete "bad → good" examples (in the original, code breakdowns existed for only a couple of sections).
  4. Practical "How to spot" and "What to do" sections — symptoms that make the problem easy to diagnose, and recommendations for fixing it.
  5. Updated for 2026 — added an analysis of AI copy-paste and code generated by large language models.
  6. Clarifications and explanations — fixed inaccuracies of the original, added definitions of terms and references to literature.
  7. Improved navigation — table of contents, cross-links and full-text site search.

What antipatterns are

It's clear that bad practices don't answer the question "how should we do it then?" — but they help you quickly understand how not to do it.

We often argue about architecture and want each other to know all the right design practices, the best world experience and "all that stuff". Of course, the real world is nothing like that. And often the worst practices are enough to start agreeing on what not to do.

I gathered the worst of the worst! It turned out there's a sea of good practices and it takes a long time to sort through them, while bad ones — genuinely bad ones — there are only a handful.

The term "antipattern" appeared as the opposite of the "design patterns" from the Gang of Four book "Design Patterns". If patterns describe proven solutions to typical problems, then antipatterns are typical solutions that in practice most often lead to problems. You can read more about antipatterns here:

Contents

That's it for now

This article doesn't cover, for example, antipatterns like Poltergeists, because it barely qualifies as one, Dead End, Input Kludge, or Blind Faith, because it should be automatically handled by tests, as well as others that are not directly related to development (or are rare from the author's point of view). If readers want, we'll look at the rest too.

Well, I'm off to keep collecting good practices, so that one day I can publish a collection of them.