antipatterns

From IndieWeb

antipatterns are antithetical to a diverse and growing indieweb, often times the opposite, or at best a distraction from indieweb principles and building-blocks, yet persistently repeated despite their tendency to waste time and cause failures.

Examples

Examples of antipatterns; this list is not comprehensive, but does reflect actual (not hypothetical) behavior seen or observed by the IndieWeb community:

hype

Hype is any inflation of something’s usefulness or even relevance beyond it’s actual real-world functionality, often evidenced by people talking about something much more than they use it (if at all), the opposite of an original IndieWeb cultural maxim of "Show more than tell", or "Show don't tell", also exemplified by the contrast between "Talkers" and "Doers".

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.

Another common phrasing of this is YAGNI (You Ain't Gonna Need It).

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

It's been noted that for some sites and silos, PESOS appears to be easier to implement than POSSE, with the excuse of: "do the easy thing now and fix it later".

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:

Exception:

  • In a community context (e.g. #indiewebcamp) it is worth investing some amount time in others' "urgent" items (especially if you can help quickly), with the expectation that later when you have something *important* to you and ask about it - the likelihood of reciprocation is greater.
  • Also contributing to a community culture of helpfulness scales well with the size of the community - as more and more people help each other quickly more and more, each of us gets our important things done faster.

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:

  • Uninspectability
  • Platform trap
  • Premature optimization

As well as alternatives to use instead and an FAQ.

design for silos or enterprise

Designing explicitly for silos or the enterprise (not Star Trek) is an anti-pattern.

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.
like we saw with activitystreams as well.
but they'll just end up complicating stuff.
it's telling that the webfinger spec has hypothetical examples of "possibilities" "

"sandeepshetty - your analysis is correct. thus, just ignore the silo people as they won't actually ship / interoperate anything anyway.
they might as well just be making a bunch of noise on a mailing list. oh wait."

"enterprise is fairly ignorable. once the open web adopts something the enterprise eventually begrudgingly adopts it too.
no need to actually include enterprise in any early (any at all?) standards discussions.
though if you can honeypot them into their own standards committees, it can help reduce the amount of noise/distraction they cause elsewhere. e.g. WS-Deathstar"

enterprise design antipatterns

Design actually done by enterprise has its own overlapping set of antipatterns, e.g.:

Related: Fatberg (illustrative of standards designed by/for enterprise, sometimes academics, sometimes both)

WS-Deathstar

"Web Services" (or WS and the suite of WS-* specs like WSDL) were a prime example of design by and for enterprise.

For reference: WS-Deathstar [1][2][3][4][5], e.g.:

1428661128_7b85fb5578.jpg
2217422218_63a7fbee63_o.png

Totally unrelated to http://deathstar.ws/ (oh if only there were some relation other than Star Wars overlap)

WS-FAQ

What is WS

mass adoption

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 eat what you cook).

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

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:

  • accidental false data
  • deliberate false data - data not specific or unrelated to the page
    • spam - often advertising a silo site as a whole rather than having to do with the specific page.
  • invisible data gets out of sync with visible data on the page
    • AKA rotten data

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:

Some services that read invisible metadata aren't good at extracting the right information from the visible page. (This is part of why they want the separate metadata in the first place.) If a site owner wants to provide, for example, OGP to ensure that Facebook uses the correct image, summary, etc., the best way to mitigate this antipattern's drawbacks is to use an update process that automatically regenerates the metadata from the visible page content when the real content is updated.

See also: invisible data considered harmful

monoculture

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

Examples:

  • Mobile WebKit: web designers that only design their mobile web content for the WebKit browser, including only using -webkit-* CSS properties
  • BuddyCloud "is an open source, distributed social network"
    • No one particular project should be considered a "distributed social network"
  • Diaspora to some degree emphasized interop with other Diaspora instances, though it did support several open standards, and thus made progress towards open interop rather than single-project-interop.
  • Tent.io has been pitched as a single project distributed social network solution.
  • ...

Antidote:

  • Encourage monoculture projects to support indieweb building-blocks and become indieweb friendly.
  • Encourage participants in monoculture projects to join IRC and signup on the Guest List to attend the next IndieWebCamp. By engaging these projects productively, perhaps we can help improve them and their cross-project interop.

object oriented programming

sidefile antipattern

Main article: sidefile-antipattern

nagging

Main article: nagging

YASNS

Main article: YASNS

cargo cult

  • cargo-cult-antipattern - the tendency of many (most?) web developers to code by rote/tradition/fashion/trends rather than actually have a rational understanding of the technologies they use and how to analyze tradeoffs therein, sometimes revealed by purely emotional responses to having their tradition/fashion/habits questioned.

well-known

  • well-known - Well-known refers to designating a common URL on domains for data to be easily located

prompt fatigue

This section is a stub. You can help the IndieWebCamp wiki by expanding it.

Don’t incessantly prompt the user upon opening a page with a bunch of dialogs (cookies, turn-off ad blocker, newsletter, notifications etc.) that get in the way of what they are trying to read or do, as illustrated by this cartoon:

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.

See Also

Retrieved from "https://indieweb.org/wiki/index.php?title=antipatterns&oldid=95702"