Stomp Complexity!

This is a kinda heady talk

Some things I hope you'll come away with:

New words, and new ideas about familiar words
New metaphors for thinking about Drupal, but systems in general
What you, individually, can do to mitigate Drupal's complexity
And that doing so is Drupal's greatest need, and highest calling

Much of this talk is proudly purloined from Rich Hickey's Simple Made Easy

(If you haven't seen it, fix dat)

a ton of this talk is lifted pretty directly from a fantastic talk given by Rich Hickey, the creator of Clojure, at Strange Loop in 2011. (but hey, it's ok, because i'm acknowledging it!)

While i did come up with the general idea for this talk before having seen Rich Hickey's talk, that talk gave fundamental shape and form to this one

but i'm going to go a different place than he did with his talk; he was focused on making an argument for functional programming. i think there's value there, and you should watch the talk, but such an argument isn't really useful for most people, who can't just switch at the drop of a hat.

i think the basic premises he outlines there are incredibly powerful. in particular, he gives us some words - both new ones, and new concepts for familiar ones - in his talk. hat's where i want to start.

Some Etymology

Simple	Easy
sim-plex	ese < aise < adjacens
one fold, braid	at leisure (to lie near)
vs complex	vs difficult

So, in a slide that is almost exactly the same as the one from his talk, let's start by looking at the words 'simple' and 'easy'.

we use these words a lot. but we'd benefit from using them more precisely. one of the great ways to do that is to look at a word's history - its etymology.
Simple, from simplus, or simplex. it quite literally means "one fold or braid." and if you picture a single braid, that just...straight. if that doesn't make sense, then think about the more familiar word "duplex."
The opposite of this is complex, as in braided together. this is a key concept in both my talk, and in Rich Hickey's - understanding what this folding looks like, and the problems with it.
Easy is a little trickier to get something good from. ese from Middle English, back through to the Old French aise. There are a lot of senses for these words, but the most relevant one here is the idea of a "lack of effort."
now, Rich found another "speculative" linkage, back to the Latin adjacens (root of adjacent). i couldn't find that linkage myself, but it serves the talk well, so i'm stealing that too. *CLICK*
this is really useful because the idea of "lying near" captures the proximity sense of "lack of effort", and that helps with the overall metaphor i'm trying to build in your mind right now.

Simple

Simple is often about 'oneness':

One content type
One responsibility, role, goal
One concept
One axis/dimension

a lack of interleaving

But simplicity does not mean just 'having one':

One node (vs two?)
One instance (vs five?)
One operation (vs ten?)

Cardinality - largely irrelevant to simplicity

Simple is instrinsic and objective

Easy

adjacens: to lie near (me)

relative, subjective

Easy: "Near, Effortless"

In our tooling:
- WYSIWYG
- Package managers
- Devel module
Close to our existing skills and knowledge
Minimal effort required for considerable utility

WYSIWYG - it's "near" to the editors' understanding, mental model of configuring digital text (is it still?)
package managers: abstract the task of collecting and installing dependencies (for your system, app, whatever)
Devel module: here, "ease" is all about locating tools in a single place

ultimately we're talking about a specific group of people, and the knowledge/experience we think they have. and we want to minimize the effort for them to pick up a new thing.

this is FUNDAMENTALLY DIFFERENT from talking about the intrinsic simplicity of a thing. (it's also one way to build an island, btw)

playing the violin is not EASY for me, but it may be EASY for many of you. or, one better - reading Braille.

Complexity as Braiding

complect - "to braid together, make complex"

decomplect - "to unbraid, tease apart"

constrast with: compose, "to place together"

The Hawk and the Hare

maths!

Prologue

There's a hare on the ground.

There's a hawk in the sky, 100 meters above.

The hawk is hungry.

Distance

The hawk can dive at 10m/s.

How long until she reaches the hare?

Acceleration

The hawk can accelerate at 3m/s/s, up to a maximum of 15m/s.

How long until she snatches the hare?

Realistic Descent

Hawks can't dive straight down - she descends in circles, tracing a conical path.

Her maximum angle of descent is 75 degrees.

How long until she grabs the hare?

Centripetal Limits

As the hawk turns more quickly through the narrowing descent cone, centripetal force reduces her velocity.

Her maximum velocity decreases linearly in proportion to the percentage of maximum turn rate reached.

Her maximum turn rate is 135 degrees per second.

At maximum turn rate, her maximum forward velocity is reduced to 33% (5m/s).

How long until dinner?

Hare: not an idiot

The hare starts moving, 3m/s in one direction.

The hawk continuously reorients on the hare as long as he's in view.

How long...

Complexity vs Reasoning

Modifying a system requires the ability to reason about its behavior
Complexity is the primary limit on our ability to reason
Our capacity to create complexity vastly exceeds our capacity to reason about it

Reasoning is the chief thing that matters when it comes to working with a system. If we can't reason about it, we can accomplish only the most rudimentary of tasks.
The complexity of a system - the number of interleaved, independent parts - is really what determines our ability to reason about a system. (use hawk story here; maybe find another)
"exceeds" is a massive understatement. our ability to create complexity is unbounded. our ability to reason about it is VERY bounded. diffrential human capabilities in reasoning are insignificant in the face of the complexity we can create
Bill, Jamal, Pooja
there is a rather obvious conclusion here: if you don't build for simplicity, your system will not scale well into complex requirements/over time, and you will leave the humans that use it grasping at straws
there's also an axiom to be had: braiding is a good metaphor, but a more practical question to ask yourself is, "how will this change i make impact peoples' ability to reason about the system?"

Simplicity is prerequisite for reliability.

Edsger W. Dijkstra

Simple and Easy are both important (and difficult)

Easy gets the attention by default. Simple requires deliberate effort.

this talk is worth giving because our collective tendency - especially in Drupal - is to tend towards ease.
Dijkstra again: "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
nevertheless, both of them are important. you can build the most elegant, simple system ever, but that does not guarantee it will be easy - and if nobody can get over the hump of learning it, does your system matter?
this is why we must ask the crucial question - whether the complexity is acceptable.
because complexity, once introduced, never goes away, whereas easy fades. complexity is carried into EVERY system that builds on yours. don't forget, it's intrinsic!
it's just that certain kinds of complexity may not matter for the use case. that - and that alone - should be the basis of the answer to acceptability question.

Simple things can usually be made Easy

The reverse does not hold

Interface vs Artifact

Easy focuses on the experience of use
- Convenience for users
- Replaceability of users
Simple is concerned with the results of use
- Quality of code, correctness
- Maintenance and future change

Simple vs Easy: Project Velocity

Simple vs Easy: Coolness

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

Tony Hoare

Better quote: Programming languages on the whole are very much more complicated than they used to be: object orientation, inheritance, and other features are still not really being thought through from the point of view of a coherent and scientifically well-based discipline or a theory of correctness. My original postulate, which I have been pursuing as a scientist all my life, is that one uses the criteria of correctness as a means of converging on a decent programming language design—one which doesn’t set traps for its users, and ones in which the different components of the program correspond clearly to different components of its specification, so you can reason compositionally about it.

The Pascal quote is more subtle. it reminds us that achieving simplicity is not easy.

Complexity in Drupal

ok, let's get a little more concrete, and talk about how all this actually applies to Drupal.
this is the part where my talk really diverges from Rich Hickey's - he's essentially making an argument for functional programming and immutable state. while he's not incorrect, his perspective is too purist to be useful for something like Drupal.
honestly, this is a little hard to do. so much of Drupal is so complected together that picking out particular points is tricky. in his talk, Rich Hickey focuses on things like language aspects - say, syntax and parens - but we have few such luxuries.
but this goes back to the earlier question: what complexity is acceptable, and why?
i'd love folks to approach me later with (fairly clean, preferably) examples of how Drupal is complected. the better these examples are, the more we can build a good set of examples, the easier it will be for people to latch on to these concepts.

Global Variables

Complects your code with ALL other code in your PHP process
Somewhat less risky because failures tend to be obvious
Also just wicked easy
But, they're hell for testing

State

Global vars are a more general problem of mutable state
Complects value with time
Weaves into everything that touches it
Cannot be mitigated by modularization

"It works, as long as no one does something stupid."

OMG, STOP SAYING THIS

i hear this ALL THE TIME from Drupal folks. hell, i say it all the time. it's one of a litany of rationalizations we give for not designing tight systems.
in my view, it's a product of many factors - the fear that someone might have a use case we can't support, and the
there's also a deeper issue here: "it works" is not a good criteria. in fact, it's a terrible criteria.
this is ALWAYS possible. we need to shift the level, though. "tried to run it on a plate of spaghetti instead of a computer" vs "gave the value 12, but the undocumented reality is that everything blows up if the value is greater than 10"
also - "it works" is not a design philosophy. it is something you accept - not something you aspire to.

Alter Hooks

Complects discrete logic through shared state
Traditionally, an "escape hatch"
In practice, often amounts to "runtime configuration"
Wreaks havoc on artifact predictability - state space is too large
Renders "correctness" a delusion

Solutions

Decomplect: tease apart complex artifacts
Simplify: make new, simpler artifacts

Hookalyzer: decomplects alters

drupal.org/project/hookalyzer
Hooks, especially alters, are strong complectors in Drupal
So, tease them apart!
Hookalyzer inspects alter data as it goes by, recording a diff for each pass

Simplification

Far easier to do in core than contrib
Try to build only on components you understand
But, three words...

Swap. Don't alter.

Recap

Simple and Easy: very different, and both important
Simplicity can enable Easy, but not vice-versa
Simple is diverse, generative; Easy is cloning, a dead end
Drupal desperately needs more simple systems, and simplicity-oriented people

The Learning Curve

Gauntlet, Thrown

Reducing complexity is the highest calling in Drupal

https://bit.ly/kiss-sdboyer

Thank You

http://sdboyer.github.io/stompcomplexity/