Some Etymology

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

• the notion of single-ness, one-ness, unarity, is a defining characterstic. i always come back to it.
• simplicity is not always clear
• i often find myself comparing the search for simplicity as being like a pig sniffing out truffles: reasoning can help me get part of the way there, but at a certain point, i'm just following instincts; there's a feeling i get when my mind latches on to something unentangled, something truly simple.

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

• however, it's perfectly possible for us to have "more than oneness" without increasing complexity
• the key here is that in each of these examples, adding more of them does not increase intrinsic complexity.
• this is because each of these things are increasing in cardinality - the count of a thing, not the number of types of things.
• if it helps, think of this as "difference of kind" - interleaving, simplicity - versus "difference of degree" - cardinality.

Simple is instrinsic and objective

• most important, simplicity is objective. it is an intrinsic property of the thing itself.
• it does not need a person looking at it for it to be simple.
• all of that is in stark contrast to ease. Ease goes away over time; simplicity/complexity never does.

OK - why is it so important we define these things?

Easy

adjacens: to lie near (me)

relative, subjective

• remember our etymology: "to lie near". near...what? well, an agent. a person. so...me!
• 'ease' is inherently subjective. and we are OBSESSED with it - as software engineers, and maybe even as humans in general.

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.

OK, just a little bit more of definitions. first, a metaphor

I really like the braiding idea as a way of describing complexity. By twisting separate things together, we create artfiacts in which it is impossible to deal separately with the individual pieces.

Problem with the metaphor is that in a braid, we can still see individual strands. In a complex system, we typically cannot identify the original constituent pieces.

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.

• the great Dutch compsci Dijkstra
• complex systems are unreliable. there are simply too many possible permutations to be able to anticipate their behaviors in all situations.
• this is an inherently human obsevation: as things become more complex, it becomes more difficult for us to reason about them, to understand and predict their behavior. this makes us less capable of ensuring their reliablity

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

Easy is blue, Simple is red.

The graph is vs time, which is really about the lifecycle of a given piece of software. Yay for wildly unscientific, unit-less graphs!

For basic projects, easy is better - complexity just doesn't enter the picture. But complexity grows over time, and there's an inflection point where simple software will allow your velocity to increase.

Simple vs Easy: Coolness

• different way of saying the same thing as the last one. ease has diminishing returns.
• if you think about it a little more deeply, though, what this really saying is that, over time, systems built around 'easy' redirect effort and skill towards solving its own internal inconsistencies, rather than the primary problem.
• in other words, yak-shaving.
• but more dramatically: "easy enables REPLICATION. simple enables INNOVATION (and replication)."

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.

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

• escape hatch amounts to kicking the can down the road. "not sure if we got this right."
• it's a bizarre thing to say, that. we're not sure if we got this right? WE WROTE IT. WE DEFINED ITS RESPONSIBILITIES.

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...

harder to point out a particular thing to do.

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

this is the final frontier that one can reach as a Drupaller. (almost) no new features - just refining, decomplecting, simplifying.

Thank You

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