Model Minded Development George Fairbanks SATURN 3 May 2016 - - PowerPoint PPT Presentation

Model Minded Development

George Fairbanks SATURN 3 May 2016

Developers weave models

Developers keep in mind many abstract yet complex models that constrain the code they write

• Domain driven design
• Design patterns
• Architectural styles
• Test Driven Design (TDD)
• Programming styles (functional, OO, procedural, etc.)
• ...

What is Model Minded Development?

Model-Minded Development generalizes across DDD, design patterns, architecture, TDD, and coding styles. It’s the general idea behind many specific ones: Modeling should be a first-class activity

Do we really need models?

Simple process 1. Get new requirement 2. Write test case 3. Edit code minimally so test passes 4. Refactor to remove code duplication 5. … repeat forever Imagine discussing with a co-worker He says “Forget this abstract stuff. Follow this simple process and be happy.” Answer: Yes we need models, but how can we convince him?

Companies: short and long-term

Short-term Cashflow Long-term R&D

Software development: short and long-term

Short-term Deliver features Long-term Build models This is my gut feel, maybe yours too

Example behavior with/without models

Without models 1. Get new requirement 2. Write test case 3. Edit code minimally so test passes 4. Refactor to remove code duplication With models 1. Get new requirement 2. Does it challenge our models? a. E.g., client-server still OK? b. E.g., domain model still OK? 3. Revise models 4. Write test case 5. Revise code to match model

Why model? Need good arguments.

For those who don’t share our gut feel, two arguments:

• 1. Programming is theory building
• 2. Programming is distributed cognition

These describe why you cannot skip modeling

Programming is theory building

Peter Naur (1985) Programming as Theory Building [P]rogramming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand. This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain

• ther texts.

Emphasis added

Understanding addition

Knowing that Memorized facts

• Know that 3+4=7
• Memorize addition table
• No answers after, eg, 6+6

No understanding; no theory Knowing how General theory of addition

• Can add small numbers
• More mistakes with larger numbers
• Addition makes numbers bigger

Understanding; a theory

Gilbert Ryle (1949): Knowing How and Knowing That

theory ≈ model

Understanding software

Compare: 1. Developer who can report facts about the program 2. Developer who can give impromptu “chalk talk” about any aspect of the program Developer #2 has a rich theory of the program

• Valuable but rare

Seed questions:

• How do we get more “chalk talk ready” developers?
• Does university do enough?
• Do current processes help or hurt?

Theory building in science

• Over time, tune theory to match past observations
• Goal: theory matches future observations

How well I understand ≈ How well theory matches future observations

• bservations

future past

Refactor theory

Theory building in programming

• Over time, tune program to satisfy requirements
• Goal: avoid “dead ends”, program can always be adapted to next requirement

How well I understand ≈ How well program can produce future output

program output future past

Refactor theory

Better understanding Worse understanding

What makes a theory valuable?

DDD breakthrough

Eric Evans, Domain Driven Design, 2004

[P]rogramming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand. This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain

• ther texts.

Peter Naur (1985) Programming as Theory Building

[P]rogramming should be regarded as a production

• f a program and certain
• ther texts.

Every feature we add to this geocentric model makes it harder to add the next feature!

Programming without theory building

Programming is distributed cognition

Long division

?????

• 45 | 13095

Long division

2??

• 45 | 13095

90

• 40

Long division

29?

• 45 | 13095

90

• 409

405

• 4

Long division

291

• 45 | 13095

90

• 409

405

• 45

45

Internal-external representations match

?????

• 45 | 13095

Roman numerals, really?

???????

• XLV | XIIIXCV

Arabic numerals, unhelpful positions

4 3 5 1 0 9 5

Internal - external model alignment

Diagram from Stroop effect, not long division

Distributed cognition

Limits to pure-internal cognition

• So we use internal + external

[D]ifferent representations of a problem can have dramatic impact on problem difficulty even if the formal structures are the same.

• - Jaijie Zhang and Donald Norman 1994

How do you steer a ship?

Challenge 1: Team

• Many people, each with partial

understanding Challenge 2: Internal-external

• Make internal sense of external

representation (charts, logs, …) Success requires:

• Compatible models across team
• Effective external representations

How do you steer a ship?

Teamwork + external representation

291

• 45 | 13095

90

• 409

405

• 45

45 Ann Bob Carl Diane

Programming: External representation

Programming bridges internal and external representations Clues in the code

• Variable name “customers”, not “x”
• Named patterns

○ Client-Server ○ Lambda ○ Observer Note: these are trivial examples; models are deep

What are our models?

You, doing “architecture recovery”

You are recognizing existing patterns / models

• “Hey, it looks like your system, broadly speaking, has 3 tiers …”
• “Is it reasonable to group these 3 boxes as related to batch processing?”
• “Can you point out which boxes have persistent state, which are stateless?”

Reusable models must be linked (Sitting in a book they do nothing)

Developers weave models into programs

• Compare: Novelist weaving a story

○ Hero’s journey, character development, foreshadowing, dramatic irony, tension/humor, …

• Programmer weaving a program

○ Reusable and ad hoc domain models ○ Patterns and styles ○ Development processes and practices

• Models are richer than we can yet describe

Types of models visible in code

Domain

• Industry standard ontologies

Solution

• Patterns

(idioms, design, architecture)

• “Programming styles”

(Cristina Videira Lopes)

• Responsibility allocation,

encapsulation, parsing Mathematical Logic

• Logic, set theory,

category theory, metamodeling

Reusable and ad hoc models

Reusable models Ad hoc models Domain

• Industry standard ontologies
• Your domain model

Solution

• Patterns

(idioms, design, architecture)

• “Programming styles”

(Cristina Videira Lopes)

• Responsibility allocation,

encapsulation, parsing

• Your patterns
• Your styles

Mathematical Logic

• Logic, set theory,

category theory, metamodeling

• Rare

Yesterday, today, tomorrow

Yesterday

Yesterday Process allocates time to modeling Yes Models are first class citizens Yes, in documents Guilt when no design docs / models Medium Domain / machine separation Yes, in documents Education (university, industry) OOA&D, spec / impl, design patterns, Formalisms and notations UML Feedback loops Medium

Today

Yesterday Today Process allocates time to modeling Yes Rarely Models are first class citizens Yes, in documents No (few documents) Guilt when no design docs / models Medium Rarely Domain / machine separation Yes, in documents Rarely (eg DDD in code) Education (university, industry) OOA&D, spec / impl, design patterns, Rarely Formalisms and notations UML No Feedback loops Medium Fast (good!)

Today: Developers build models anyway

Good news:

• Lots of intellectual curiosity
• Lots of laziness (DRY)
• Management tolerates some “slack”

○ I.e., “figuring things out” that isn’t immediately delivery focused But:

• Model building discouraged by

process, done “on the side”

• Not taught directly
• Social stigma: “Modeling with the

door shut”

Tomorrow: “Balanced” systems and models

Systems and models ready for the next requirement

program output future past

Tomorrow: Developers who can “chalk talk”

Ready to talk about:

• Zoom in / out
• Technical debt
• Crosscutting concerns
• Evolving requirements

Not just greybeards:

• High % of engineers
• In mid-20’s
• Taught in university

Tomorrow: Processes promote model building

Model building as first-class activity

• Models in code, on whiteboards, in docs, in conversations
• Brute force solutions as a code smell

○ E.g., IF statement instead of improved model ○ Avoid coding “knowing that”

• Result: More “senior” engineers faster

○ Achieve internalized rich models at younger age

Tomorrow: Universities teach modeling

Undergrads should be taught model building explicitly

• Developers I see have ~8 years programming experience

○ … and 0 years modeling experience ○ So: Teach general techniques explicitly

• Activate those techniques in context

○ eg OS models, DB models, Domain models

• Refactor “documentation” books as “modeling” books

○ Documenting Software Architectures (SEI++) ○ Requirements Engineering (Van Lamsweerde)

Model Minded Development

Developers keep in mind many abstract yet complex models that constrain the code they write. Model-Minded Development generalizes across DDD, design patterns, architecture, TDD, and coding styles.

• 1. Programming is theory building
• 2. Programming is distributed cognition

Modeling should be a first-class activity