The Abstract Art of Software Development

Jean Piaget

Developmental stagesSensorimotor

Preoperational

Concrete Operational

Formal Operational

Preoperational

Age 2 to 7

Magical Thinking

Why?

Script Kiddies

Copy and Pasters

Concrete Operational

Age 7 to 11

Thinks logically about problem and systematically tackles it

Focuses on the problem

Large blocks of code

Nested Ifs

Repeated Functionality

Formal Operational

Age 11 to 15-20

Abstraction

Meta-cognition

Problems belong to classes instead of one offs

How a problem is solved is as or more important as solving it

Characterized by comfort with abstraction

Abstraction

Strunk and White Elements of StyleOmit needless words.

Omit needless information

The Big Question

How do we figure out what is needless and what is needed information?

Abstract Painting

Move away from strict representation

Remove aspects of the painting

Convey impression, theme, idea, emotion, etc.

The Starry Night van Gogh

Guernica - Picasso

Nude Descending a Staircase No. 2- Duchamp

Composition ii - Mondrian

Step 0

Where are we?

Where are we going?GoalsMetrics

Focus is on solving the problem not on making the solution

Three aspects of Software Development

DesignDetermine how the domain should work

CodeDetermine how to implement design

UICreate the user experienceInterface with the code

Read the data

Modify the data based on the domain design

Clarity

Understanding a problem = being able to reduce it to the only important parts

Step 0What do we want to do?

What do we know?

What is the least we can do this with?

Focus on what changes

If I change this, does it matter?

A process has two points of changeData inputs

Internal processing based on conditionsThis is process state

Inputs

What does this process actually need to know to do what it is supposed to?

What information do the system need that it does not know?

Is this input actually needed?

Is it actually used in the core of the process?

Is it already available either through another piece of input or as part of the system?

Am I actually using this input, or just a property of it?

Generalizability

Understanding Comics: The Invisible Art Scott McCloud

Models

Contain only the aspects of the thing modeled that are relevant to the situation

Lets you use the same process across a very different objects, as long as they can fit the model

Creating a model (or interface) lets design to the situation

Can use a intermediate converter to make a model out of something

MVC many models to one view

View Model Interface

A view can have a defined interface for how it gets handles the model data.

Providing a translation from your data models to the interface will allow the view to display and interact with it

A table can display a 2d array, a list of objects, steps in a mathematical series, etc.

MVC many views for one model

Multiple view types of the same model

A single data entity can be displayed by any number of views

e.g. Song

Audio in media player

Music staff with lyrics

Word Cloud

Etc.

Abstraction collision

Push a button versus generalized

What are your goals?

Start Date/End Date anti-pattern

States

How to identify states

If you change this, does it change behavior?

Externally handledConditionalsIf

Loops

EncapsulatedSubclasses with different processing

Lambdas and/or method references

Make your states explicit

What is the reason for the branch in behavior?

Take complicated conditionals and abstract them to descriptive methods

If (movie.author == George Lucas && movie.containsCharacter(Jar Jar Binks)) if (isTerribleStarWars(movie)

Explicit states

Communicates why branching occurs

Can be shared

Can be overriden This is great for testing

Change (and repair)

Single Paths

Eliminate needless duplication

Present clear entry points for a process that are as accepting as possible

Identify when entering that process is earliest possible

If you are copying pasting code (even to alter it slightly), strongly consider combining them

Reduce mutating a property to as few paths as possible

Units of Work

Be able to describe what something does in simple English before someone gets bored

Rule of thumb: As soon as you say And then..., it's a new unit of work

Non-trivial blocks for if then or loops are units of workPrefer tying them to the conditional states

Embrace levels

Core concept of traditional software abstraction

Single entry point opens up to all possible state combinations pathways

Each level only needs to know what it needs to know

Accept what is given without knowing the source

Single Responsibility Principle

Prefer housing all logic on one path (i.e. don't split your processing across unrelated sections of the code, between code and database, etc.)

Keep your object graph complete over the process (i.e. have all necessary data accessible through code/no explicit database calls)

Communication

Names

Choose names that convey information

Method name what does this method actually do

Variables what is this thingvar x < int maxOccupancy

adjectives (temp) and general nouns (num) should modify nouns

In defense of Hungarian notation

http://www.joelonsoftware.com/articles/Wrong.html

In cases where you can't represent type information with classes, etc., encoding that information into the name is better than not

Don't forget step 0 What's my goal?

Don't encode duplicate or otherwise useless information

Speak the language

What are you actually presenting?

It's not pages

It's not components

It's domain data and actionsUnderstand the aspects of this data and actions

Presenting these together makes up the user experience

Mise en place

Consider: Dimensions

Objects data properties that are comparable

Two types:Directly comparable (i.e. determinable difference in magnitude)

Enumerable (can be mapped to a defined list)

Use or create a vocabulary

Sapir-Whorf hypothesis

PidginQuick communication

Concerns itself only with what matters

Establish a contract

Any barrier should have clear indication of what is expected/what is not allowed

In a perfect world, derive code from the contract

Opinionated vs. Non-opinionated

What you choose to display or not display and what actions are and are not available should be meaningful

Non-opinionatedShow everything/allow everything

OpinionatedGuides the user in the intended use by reducing what is shown/allowed

Merging the two?

Avoid needless choices

Affordances

Steve ErdmanSteve.erdman77@gmail.com@MrSquicky