Model-Minded Development George Fairbanks GOTO London 13 October - - PowerPoint PPT Presentation

Model-Minded Development

George Fairbanks GOTO London 13 October 2016

Programming!

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

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

Gilbert Ryle (1949): Knowing How and Knowing That

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

while (true) {

• bserve world;

if (surprise) {refactor theory}; }

• bservations

future past

Refactor theory

Theory building in science

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

How well I understand ≈ How well theory matches future observations

• bservations

future past

Refactor theory

Theory building in programming

while (true) { pick up new requirement; if (surprise) {refactor theory}; }

program output 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

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

Building theories!

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 With scribbles on paper, we can solve problems that don’t fit in our heads

Internal-external representations match

?????

• 45 | 13095

But not just any scribbles

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

Distributed cognition: summary

• Can solve bigger problems with a pencil
• … but only if models align between paper and head
• Teams must share models
• … and their external representation
• We express our models in source code
• … for us, for our team

Distributed cognition! (as a team)

Where are we?

• Gut feel that models are helpful
• Learned about theory building

○ Parallels between science and programming

• Learned about distributed cognition

○ Can solve bigger problems with a pencil ○ … but only if models align between paper and head

• So … what are our models?

What are our models?

“von Neumann architecture”

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

Model-Minded Development

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

Goal: “Balanced” systems and models

Systems and models ready for the next requirement

program output future past

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

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 your team?

Programming! Theory building! Distributed cognition!