Inbox - got an antipattern you think needs documenting? add it here with a brief one sentence summary and maybe someone will start a page on it.
at some point
Reasoning or justifying something by saying "at some point" does not lead to good (well-informed / accurate) conclusions.
Many a spec/standard/protocol/format has been overdesigned or made prematurely complex due to "at some point" reasoning - typically followed by a theoretical requirement framed as "someone will need to ..." or "we'll have to ...".
It's flawed methodology that gets in your way if you're actually trying to build things that work today, can be incrementally improved, and sustainably grown.
Alternative: resist the temptation to design for "at some point", and instead design for the very next thing that is annoying you the most (itching) about your own site. And then iterate. Only by doing so can you actually get to that "at some point" future, and when you get there, since you proceeded incrementally, there's a much better chance that you've arrived there with a minimum of wasted effort chasing down theoreticals that turned out to not be probable, or not matter.
easy urgent vs harder important
This is a trap in practice because the "fix it later" task starves due to distraction by too many "easy thing now" items which keep getting more attention due to their apparent easiness/urgency. It's empty/hollow/unreliable reasoning/planning.The generalization of this effect is known more commonly as:
urgent at the expense of the important
More on this effect and approaches for avoiding this prioritization antipattern:
The "easy urgent vs harder important" antipattern is somewhat related to the above "at some point" antipattern but is not the same.
The "at some point" antipattern is about things that are harder and appear to *theoretically* be important but are actually unimportant in practice.
databases for storage
Main article: databases-antipattern
For any content you care about it, don't put the primary copy in a database.
Databases are all a pain to maintain (i.e. highly human-time inefficient - see also DBA tax), and more fragile than the file system.
A DBA tax includes the (often regular) hassles of: setting up a database, setting up/doing tables, setting up username/login that is database specific, altering tables, dealing with username/login that is database specific, exporting, importing, special backups.
All extra crap (thus tax) compared to "just" using the file system.
All databases have a DBA tax.
Common content management systems (e.g. WordPress, Drupal, MediaWiki etc.) use databases for primary storage of content, and thus saddle their users with a continuous DBA tax just to maintain their site.
Experience and evidence shows DBA tax exists as well. People lose things (and have them corrupted) in databases all the time, far more often than in file systems. This is because databases always require extra "magic" for backups etc.
E.g. search the web for people complaining about having to backup their WordPress databases before upgrading their WordPress install.
See the databases-antipattern article for more details about specific problems with using databases for storage like:
As well as alternatives to use instead and an FAQ.
design for silos or enterprise
Some quotes from IRC (feel free to structure this section into a more general explanation)
"what pisses me of even more is that all the silo ppl asking for it... will not end up using it.
"sandeepshetty - your analysis is correct. thus, just ignore the silo people as they won't actually ship / interoperate anything anyway.
"enterprise is fairly ignorable. once the open web adopts something the enterprise eventually begrudgingly adopts it too.
Totally unrelated to http://deathstar.ws/ (oh if only there were some relation other than Star Wars overlap)
Definitely related: Fatberg
What is WS
The methodology of attempting to design directly for "mass adoption" or "mainstream adoption" is an antipattern and will likely be an obstacle to actually designing something useful, especially for yourself (vis-a-vis self-dogfooding).
AKA the "design for everyone" anti-pattern.
The appeal of design for "mass adoption" (and/or having that mindset) is the illusion that it is actually possible to do so successfully and quickly get everyone to use whatever it is you're building.
Designing for "mass adoption" is one of the traps that many past federated/social web efforts fell into.
It's a form of distraction: instead of designing/building what's immediately useful to you, the creator, you end up ratholing on what "everyone" or "the average person" seemingly wants, which is purely hypothetical, because you don't actually know what everyone or the average person wants - you're just making guesses and assumptions. The problem with designing for something so theoretical is that you will never know if you're on the right track or not. Design for yourself and get immediate rapid feedback which you can use to quickly iterate, try experiments, change things around, continuously incrementally improve things etc.
What's perhaps worse is that even if you find this theoretical "average person" who is willing to try out your service, you will then get distracted by all their random support requests rather than actually creating something with a cohesive vision. Note: it's not that hard to acquire a bunch of seemingly average person users (up to 50k+!), and they don't mean anything. See:
It's also bad to transition to designing for mass adoption rather than yourself and actual users, as as soon as you do so, you begin turning your creation into crap, and start down an inevitable downslide (early adopters leaving etc.). It's a huge fallacy that silos and open source projects fall into (due to the apparent appeal.)
Designing for mass adoption is one reason why silo user experiences in general get worse over time. Which is also an opportunity for you, as a creator and contributor to the indieweb, to not just match but do better than the silos with the user experience on your own site.
It can also be a vulnerability, e.g. if "this will only be useful once everyone adopts it", you're likely building something that is vulnerable to either never being useful, or becoming useless when adoption fades.
Invisible metadata is the general antipattern of storing information that is user-relevant in places users won't see (i.e. users aren't expected to "View Source" on every page).
The problem is that absent an immediate visible feedback loop on such data, it has numerous problems:
The use case for invisible metadata is to make data available to computers but not visible to people. For example, User:Snarfed.org and others would like to make their h-card's photo available to webmention consumers, so that e.g. they appear in comments-presentation, but not visible on their home pages. See also h-card#Issues.
Examples of encouragements to use invisible metadata:
See also: invisible data considered harmful
The monoculture antipattern is best described as, if only everyone would install and run this one open source project then we will be good.
Main article: monoculture
object oriented programming
Main article: object-oriented-programming-antipattern