“Simplicity is a prerequisite for reliability”
- Edsger W. Dikstra
Word Origins
Simple
- Sim- plex
- one fold/braid
- vs complex
Simple
One fold/braid
- One role - One task - Once concept - One dimentionBut Not
- One instance - One Operation- About lacking of interleaving not cardinality
- Objective
Easy
- ease < aise < adhacebs
- lie near
- vs hard
Easy
- Near, at hand
- on our hard drive, in our tool set, IDE, apt get, gem install
- Near to understanding
- Familiar
- Near our capabilities
- Easy is relative
Construct vs Artifact
- We focus on experience of use of construct
- programmer convinience
- programmer replaceability
- Rather than the long term results of use
- software quality correctness
- Maintainable, change
- We must assess constructs by their artifacts
Limits
- We can only hope to make reliable those things we can understand
- We can only consider a few things at a time
- Intertwined things must be considered together
- Complexity undermines understanding
Change
- Change to software require analysis and decisions
- What will be impacted?
- Where do changes need to be made?
- Your ability to reason about your program is critical to changing it without fear
- Not talking about proof, just informal reasoning
Debugging
- What’s true of every bug found in the field?
- it has passed the type checker
- and all tests
- Your ability to reason about your program is critical to debugging
Development Speed
- Emphasizing ease gives early speed
- Ignoring complexity will slow you down over the long haul
- On throwaway or trivial projects, nothing much matters
Easy Yet Complex?
- Many complicating constructs are:
- Siccinctly described
- Familiar
- Available
- Easy to use
- What matters in the complexity thy yield
- Any such complexity is incidental
Benefits of Simplicity
Lego castles are better than concrete ones.
- Ease understanding
- Ease of change
- Easier debugging
- Flexibility
- Policy
- Location (etc)
Making Things Easy
How easy things are is the distance between you and what you’re trying to achieve. Making things simple, will actually make things easier
- Bring to hand by installing
- getting approved for use
- Become familiar by learning, trying
- But mental capability
- not going to move very far
- make things near by simplifying them
Parens are Hard!
- Not at hand for most
- Nor familiar
- But are they simple?
- Not in CL/Scheme
- overloaded for calls and grouping
- Adding a data structure for grouping, e.g. vectors makes each simpler
- overloading is complexity reduced by adding more things
“LISP programmers know the value of everything and the cost of nothing.”
- Alan Perlis
Not only benefits! We need to look for trade off’s
What’s in your toolkit?
child_database
Complect
- To interleave, entwine, braid
- Don’t do it!
- Completing things is the source of complexity
- Best to avoid in the first place
Compose
- To place together
- Composing simple components is the key to robust software.
Modularity and Simplicity
- Partitioning and stratification don’t imply simplicity
- but are enabled by it
- Don’t be fulled by code organization
State is Never Simple
- Complects value and time
- It is easy, in the at-handed and familiar senses
- Interweaves everything that touches it, directly or indirectly
- Not mitigated by modules, encapsulation
- Note - this has nothing to do with asynchrony
Not all refs/vars are Equal
- None make state simple
- All warn of state, help reduce it
- Clojure and Haskell refs compose value and time
- Allow you to extract a simple value
- Provide abstractions of time
- Does your var do that?
The Complexity Toolkit
child_database
Environmental Complexity
- Reources, e.g. memory, CPU
- Inherent complexity in implementation space
- All components contend for them
- Segmentation
- waste
- Individual policies don’t compose
Abstraction for Simplicity
- Abstract
- Drawn away
- vs Abstraction as complexity hiding
- I don’t know, I don’t want to know
Simplicity is not an objective in art, but one achieves simplicity despite one’s self by entering into the real sense of things.
Lists and Order
- Sequence of thigns
- Does order matter?
- [first-thing second-thing third-thing …]
- [depth width heigh]
- set[x y z]
- order clearly doesn’t matter
Why Care about Order?
- Complects each thing with the next
- Infects usage points
- Inhibits change
- [name email] →
[name phone email]
Order in the Wild
child_database
Maps, Dammit!
- First class associative data structures
- Idiomatic Support
- Literals, ancessors, symbolic keys
Information is Simple
- Don’t ruin it
- By hidding it behind a micro-language
- i.e. a class with information specific methods
- thwarts generic data composition
- ties logic to representation du jour
- Represent data as data.
Encapsulation
- Is for implementation details
- Information doesn’t have implementation
- Unless you added it - why?
- Information will have representation
- have to pick one
Can You Move it?
- Litmus test - can you move your subsystems?
- out of proc, different language, different thread?
Subsystems Must Have
- Well defined boundaries
- Abstracted operational interface (verbs)
- General error handling
- Taken/return data
- IPersonInfo -oops!
- Not just a matter of serializers
Simplicity is a Choice
- Requires Vigilance, sinsibilities and care
- Your sensibilities equating simplicity with ease and familiarity are wrong
- Develop sensibilities around entanglement
- Your reliability tools (testing, refactoring, type systems) don’t care if simple or not
- and are peripheral to producing simple software.
Simplicity Made Easy
- Choose simple constructs over complecity-generating constructs
- It’s the artifacts, not authoring
- Create abstractions with simplicity as a basis
- Simplify the problem space before you start
- Simplicity often means making more things, not fewer.
“Simplicity is the ultimate Sophistication”
- Leonardo Da Vinci