Patterns, Anti-Patterns, Dark Patterns

[skreutzer]

What are patterns, simply speaking? Certain repeatable steps forming a procedure/method that reliably leads to the same result/outcome, similar to software algorithms, cooking recipes, in textile weaving, mathematical formulas, and so on. In some sense, everything might be a pattern, or Alan Kay explaining that we as humans are too patterns that move through time and space. In software development, there's the Gang of Four recommending code solutions to common programming problems. Software is a very shapeable material/medium to work with. Physical architecture to some extend too, in comparison to other domains, especially during the initial design/planning phase. Christopher Alexander's collection of patterns serve a humanistic purpose and are therefore on another level altogether. The meta pattern beyond it forming his particular pattern language expresses his philosophy which can be discovered in, read from his collection of patterns and also instructs of how these patterns were picked or how to pick them. It's not just a collection of some arbitrary patterns that sometimes might useful for something, but selected after careful consideration in contrast to the ignorant architecture that happens to be good enough to not collapse in terms of engineering recipes, but not working for the humans who inhabit the space and the environment. Douglas Engelbart would be another example of a humanistic + systemic approach, searching for patterns for collaboration in order to solve urgent, complex problems.

Anti-patterns in software development might very well appear to be regular, good patterns, and with the initial promise outlined above that well-selected patterns always lead to favorable outcomes, the blind application of ill-selected, flawed patterns can cause more harm than improvement or too be completely pointless, but such anti-patterns can persist on the basis that they happen to merely gain popularity, or that they're a seemingly obvious, lazy route to go without realizing or bothering to avoid the major disadvantages that get newly introduced by the application of an anti-pattern. Not sure if Christopher Alexander has the notion of an anti-pattern in the domain of architecture, but as (his) patterns are supposed to be good and the good ones by definition (why otherwise collect them and formulate a language of anti-patterns?), there's not much reason to discuss in length all the non-patterns or anti-patterns or the absence of patterns that don't lead to favorable results anyway.

Dark patterns in software design are a category of patterns that deliberately serve the purpose of influencing the user towards doing things that normally wouldn't be in his/her interest or favor, while also ideally being very subtle and not recognizable as dark patterns.

Who needs patterns? People who design or build things or have to make decisions. Additionally, one might not have a lot of experience, knowledge, wisdom available or the time/capacity to figure out what to do best himself/herself, therefore preexisting, well-selected patterns are supposed to offer a shortcut while also guaranteeing a good result.

Where do patterns come from? Sometimes they might be sequences of universal validity, but in order to become recognized and useful as such for humans, to become applicable, their expression and selection as a pattern is be needed based on the observation and analysis of such sequences. Another option is to actively design new patterns by carefully considering the potential systemic side effects that might render the pattern useless or even harmful in certain use cases, and only keeping those patterns which most of the time or always lead to favorable results.

Enough for this attempt of a simple overview/introduction, trying to avoid all the artificially complex theory and jargon, while focusing on the practical reasons of why and how to deal with "patterns" to begin with. Feel free to object to what's wrong, add what's missing, or engage in discussion about if any of this makes sense or instead is all confused/confusing and/or misleading.

[Stephan Kreutzer]

It's common to consider patterns in software development to be the other prime example of Christopher Alexander's pattern methodology. I'm just not clearly convinced yet that this is actually really the case. The main work in the domain of programming is "Design Patterns" by the Gang of Four, and in contrast to Alexander's pattern language for architecture, as he himself seems to suggest/wonder, they could be more of an arbitrary collection of non-related best practices that also lack the humanistic purpose as well as the overall systemic architectural approach. Just listen to

    https://www.youtube.com/watch?v=98LdFA-_zfA

on the potential fundamental differences between Alexander's work/approach/proposal and how software engineering interpreted/reframed it. The domain of architecture with physical material is fundamentally different from architecting software in formal computational logic - different rules, different effects, different costs to everything, so one should be careful to quickly draw comparisons. Software design patterns have their equivalent anti-patterns, but I've seen one presentation by a software developer who suggested that anti-patterns might be something different than just bad patterns to avoid, if interpreted in the sense Alexander proposed his definition of what a pattern is.

--
You received this message because you are subscribed to the Google Groups "Peeragogy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to peeragogy+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/peeragogy/c65ba3a0-322f-4713-90b5-319cbd20f542%40googlegroups.com.

[Roland Legrand]

Thank you so much Stephan for this thoughtful intro!

[Joe Corneli]

Hello, that is a very nice distillation thank you. I would be interested to know more about that developer mentioned who discussed anti-patterns.

 Here are a few more elaborations. 

If I think about patterns today, and what comes to mind for me is repetition, because I was talking  with my aunt yesterday and she explained how crystalline structure appears throughout the human anatomy at the micro-scale. This would be consistent with Christopher Alexander’s idea about patterns being that which contributes to life. Which is basically where his later books are going.

 But we should not lose track of the earliest papers from Christopher Alexander either, this division of patterns into problem, solution, rationale. The structure only is repeated because the problem is frequently encountered, the solution works, and is a good one.

 I’d need to refresh my self on Deleuze to be very precise, but we can compare his philosophy of difference in a high-level way. I think that to some extent I had managed to square this circle in the paper “patterns of design” which is linked from my website.  Part of the idea being that the solution and the problem are quite different.  But the problem itself is meant to be different as well, insofar as it is a problem, and isn’t something that we already have a routine solution ready for.

So something like a pattern language is the beginning of a crystallisation in a repeatable form of an analysis of a problematic field.  There is an interplay between this structure and the identification of new problems.

Another useful reference point would be what Brian Arthur calls the -ology of technology. Technology is give a material repeatable structural form to problem-solving methods.  Much as with Alexander’s system, new technologies are made out of combinations of old technologies.

 Here, humaneness comes into it because technologies address human needs. However they also create other needs because they create new problems. I don’t know if there is one unified humane solution to this whole quandary, but I do think that something like peeragogy is relevant here, because it can help us think about How people learn together.  To round things out I should probably mention Eleanor Ostrom and her theory of institutions, Because this theory gives a fairly elaborated and systematic way to approach collaborative learning, and because it also resonates with the basic pattern theory. At least that’s how I see it. I talked about some of this in another paper called “an institutional approach to computational social creativity”.

In the spirit of our peeragogy patterns, I wonder what’s next? What are we driving out when we talk about patterns here? How do the patterns such as the ones detailed in the book help us understand the problems and quandaries that we are facing?   And what’s missing, what things do they not help us think about and solve? 

[skreutzer]

I would be interested to know more about that developer mentioned who discussed anti-patterns.

To answer this particular point in advance, it's a talk by Felix "fefe" von Leitner, who maintains a leightweight C runtime library started by him, ran "Paperboy" before it was shut down by lawsuits of newspaper publishers and before Google News started to do the very same thing, today working as a code auditor and continues a blog to teach media competency by critically interpreting the media and events (for the reader to figure out if and where there may be conspiracies behind it), but also blogging about technical software topics, digital, politics and ethics.

The talk in question is

    https://media.ccc.de/v/34c3-9095-antipatterns_und_missverstandnisse_in_der_softwareentwicklung#l=eng

of which there is an English translation (unfortunately, only the recording of simultaneous translation for the attendees at the conference). This might be a potentially revised version of the slides

    https://ptrace.fefe.de/admin-antipatterns

(with images removed for copyright reasons).

The blurb says: Based on anecdotes from 20 years of software development, this talk tries to examine, what, in practice, leads to projects failing. It is not about programming errors, but about things which are done for the wrong reasons -- for example, to recode a monolithical application into a microservice architecture, but ending up with a distributed monolith. A common pattern is [I guess the blurb means that this is the general nature/character the selected patterns in his talk share and which he considers them to be anti-patterns, basically his meta-pattern or the anti-pattern language behind it] that advantages of an approach are intentionally/deliberately avoided with surgical precision, while every single disadvantage gets included generously.

The introductory slide says: "An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive". Him then going into details and specific examples/patterns without discussing the meta-theory much, I think his definition suggests that these anti-patterns are used/applied, widespread and popular because they appear to be obvious/convenient/simple or good, regular patterns (in Christopher Alexander's sense maybe), but in fact are not at all, and they're not just ordinary bad patterns one knows or has learnt to avoid (just as one has learnt to apply the simple best practice recipes) like "GOTO considered harmful" or Brooks' law, but are reasonable-sounding solutions almost by the book, but misinterpreted, wrongfully applied (Robert's question about patterns in context) or appearing to have certain favorable outcomes, while the opposite is the case most of the time or always. There could be a collection/language about these to avoid them as bad patterns, but they are anti-patterns because their use just like the good patterns is caused by a lack of systemic understanding and ignorance towards favorable, humanistic design.

Note that this particular talk is not about "design patterns" for software architecture or programming best practices, which might be sufficiently different in nature to be safely compared with what Alexander had in mind regarding the domain of physical architecture, and this (new) notion of anti-patterns presented in the talk I've referenced.

Maybe this is already quite over-engineering, theorizing, what otherwise can be more simple and straight forward in actual practice.

[Joe Corneli]

"advantages of an approach are intentionally/deliberately avoided with surgical precision, while every single disadvantage gets included generously."

That reminds me of the term "zemblanity", which is supposed to describe the opposite of "serendipity".

"An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive"

That's a nice definition.  "Defusing" antipatterns seems like an interesting challenge area.

"reasonable-sounding solutions almost by the book, but misinterpreted, wrongfully applied or appearing to have certain favorable outcomes, while the opposite is the case most of the time or always"

This gloss is helpful for me!

"Maybe this is already quite over-engineering, theorizing, what otherwise can be more simple and straight forward in actual practice."

Maybe - but at least so far in the peeragogy project, we haven't (yet) been systematically looking at "failures", which is an oversight that hopefully can be corrected in v4.  In general, people often focus on positive examples, the "case study methodology", which could risk running into the kinds of antipattern problems you've highlighted if no one bothers to check up on long term outcomes or unexpected side effects.

[skreutzer]

With the examples given by the Wikipedia for the term "anti-pattern", I find it interesting at least that in most cases, nobody intentionally applies anti-patterns in order to deliberately cause their bad effects/results, but for the reason and in the expectation that some good, favorable outcome might arrive, which then it either does not (never, can't per nature of the anti-pattern) or not in a systemic, holistic, humanistic overall way. When searching for patterns in architecture, it's the careful, considered choice of which patterns are the real, good ones from all the possible recipes and options out there, to recommend the former instead of randomly, uninformedly doing any of the others, but anti-patterns don't seem to be primarily the approaches that don't work (which tend to be fairly obvious and easy/quick to check in the domain software, objectively measurable, therefore a big bunch of them can be avoided altogether), but bad patterns that continue to be widely used because the disadvantageous results caused by them are/remain unknown or ignored under the false impression that such a pattern might be able to generate an upside.

In the context of the Peeragogy Handbook, as patterns are a frequent/popular subject of discussion of course here and beyond (and besides from the theoretical discussion, the handbook appears to be in part a handbook of patterns), I just wanted to start some text that asks the question if patterns are all the same and comparable in different domains. Reading the "Patterns" chapter after it, the general description/introduction of "What is a pattern?" is pretty similar, but just for internal reflection we and readers might wonder if Peeragogy patterns are meant in an Alexander sense or software development "design patterns" recipe sense, or somewhere in between, or something entirely new/different. Not that this needs to be answered explicitly, it can also emerge from Peeragogy practice and/or the further development of the handbook.

[skreutzer]

Good points! I overlooked the inherent repeating/reoccurring nature that the pattern structure/design/rule generates for the observer, while the "repeatable" is the relevant property for the user/applicant. In Alexander's architecture however, the repetition is relatively indirect or on a meta-level (for example, patterns that generate variation - which by the design of the pattern isn't random chaos and instead a deliberate design choice, but also not monotone, linear, stringent, identical sequences) a layperson might not even be able to explicitly identify/describe (in contrast to patterns related to formal logic systems).

As you seem to be fully aware that in terms of patterns, the question of technology as well as systemic system change are both another big bag of worms of their own to maybe not open right now, I'm just a little bit puzzled if there's confusion about these topics, as observations about pattern principles in other domains might indicate how one could translate, interpret, evaluate, improve what they might mean in the context of the peer principle as well as pedagogy.