This document discusses different stages of software development and abstraction. It covers Piaget's stages of cognitive development as they relate to programming. The key stages discussed are preoperational, concrete operational, and formal operational. The document advocates reducing problems to their essential parts through abstraction. It provides examples of abstract painting and emphasizes focusing on the problem being solved rather than the solution. It also discusses various software development principles like separation of concerns, single responsibility, and establishing clear communication through naming conventions and language.

1. The Abstract Art of Software
Development

2. Jean Piaget
● Developmental stages
– Sensorimotor
– Preoperational
– Concrete Operational
– Formal Operational

3. Preoperational
● Age 2 to 7
● Magical Thinking
● Why?
● Script Kiddies
● Copy and Pasters

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

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

8. Abstraction
● Strunk and White – Elements of Style
– “Omit needless words.”
● Omit needless information

9. The Big Question
How do we figure out what is needless and what
is needed information?

10. Abstract Painting
● Move away from strict representation
● Remove aspects of the painting
● Convey impression, theme, idea, emotion, etc.

11. The Starry Night – van Gogh

12. Guernica - Picasso

13. Nude Descending a Staircase No.
2- Duchamp

14. Composition ii - Mondrian

15. Step 0
● Where are we?
● Where are we going?
– Goals
● Metrics
● Focus is on solving the problem not on
making the solution

18. Three aspects of Software
Development
● Design
– Determine how the domain should work
● Code
– Determine how to implement design
● UI
– Create the user experience
● Interface with the code
● Read the data
● Modify the data based on the domain design

19. Clarity
● Understanding a problem = being able to
reduce it to the only important parts
● Step 0
– What do we want to do?
– What do we know?
– What is the least we can do this with?

22. Focus on what changes
● If I change this, does it matter?
● A process has two points of change
– Data inputs
– Internal processing based on conditions
● This is process state

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

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

26. Generalizability
Understanding Comics: The Invisible Art – Scott
McCloud

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

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

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

30. Abstraction collision
● Push a button versus generalized
● What are your goals?
● Start Date/End Date anti-pattern

31. States

32. How to identify states
● If you change this, does it change behavior?
● Externally handled
– Conditionals
● If
● Loops
● Encapsulated
– Subclasses with different processing
– Lambdas and/or method references

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

34. Explicit states
● Communicates why branching occurs
● Can be shared
● Can be overriden
– This is great for testing

35. Change (and repair)

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

37. 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
work
– Prefer tying them to the conditional states

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

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

40. Communication

41. Names
● Choose names that convey information
● Method name → what does this method
actually do
● Variables → what is this thing
– var x < int maxOccupancy
– adjectives (“temp”) and general nouns (“num”)
should modify nouns

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

43. Speak the language

44. What are you actually presenting?
● It's not pages
● It's not components
● It's domain data and actions
– Understand the aspects of this data and actions
– Presenting these together makes up the user
experience

45. Mise en place

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

47. Use or create a vocabulary
● Sapir-Whorf hypothesis
● Pidgin
– Quick communication
– Concerns itself only with what matters

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

50. Opinionated vs. Non-opinionated
● What you choose to display or not display and
what actions are and are not available should
be meaningful
● Non-opinionated
– Show everything/allow everything
● Opinionated
– Guides the user in the intended use by reducing
what is shown/allowed

51. Merging the two?

52. Avoid needless choices

53. Affordances

55. Steve Erdman
Steve.erdman77@gmail.com
@MrSquicky