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 Imagine discussing with a co-worker 1. Get new requirement He says “Forget this abstract stuff. 2. Write test case Follow this simple process and be happy.” 3. Edit code minimally so test passes 4. Refactor to remove code duplication … repeat forever Answer: Yes we need models, but how can we convince him?
Companies: short and long-term Short-term Long-term Cashflow R&D
Software development: short and long-term Short-term Long-term Deliver Build features 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 With models 1. Get new requirement 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 2. Write test case 4. Write test case 3. Edit code minimally so test passes 5. Revise code to match model 4. Refactor to remove code duplication
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
[P]rogramming properly should be Peter Naur (1985) regarded as an activity by which the programmers form or achieve a Programming as certain kind of insight, a theory , of the Theory Building 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 other 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 Knowing how Memorized facts General theory of addition Know that 3+4=7 Can add small numbers ● ● Memorize addition table More mistakes with larger numbers ● ● No answers after, eg, 6+6 Addition makes numbers bigger ● ● No understanding; no theory Understanding; a theory theory ≈ model Gilbert Ryle (1949): Knowing How and Knowing That
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) { observe world; if (surprise) {refactor theory}; } Refactor theory observations past future
Theory building in science Over time, tune theory to match past observations ● Goal: theory matches future observations, many observations without refactoring ● Refactor theory observations past future How well I understand ≈ How well theory matches future observations
Theory building in programming while (true) { pick up new requirement; if (surprise) {refactor theory}; } Refactor theory program output past future
Theory building in programming Over time, tune program to satisfy requirements ● Goal: avoid “dead ends”, program can always be adapted to next requirement ● Refactor theory program output past future How well I understand ≈ How well program can produce future output
What makes a theory valuable? Worse understanding Better understanding
DDD breakthrough Eric Evans, Domain Driven Design, 2004
[P]rogramming properly should be Peter Naur (1985) regarded as an activity by which the programmers form or achieve a Programming as certain kind of insight, a theory, of the Theory Building 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 other texts.
Programming without theory building Every feature we add to [P]rogramming should be this geocentric model regarded as a production makes it harder to add of a program and certain the next feature! other texts.
Example behavior with/without models Without models With models 1. Get new requirement 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 2. Write test case 4. Write test case 3. Edit code minimally so test passes 5. Revise code to match model 4. Refactor to remove code duplication
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?
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 ●
Teamwork + external representation 291 ------- Diane Ann 45 | 13095 90 -- Bob 409 405 --- 45 Carl 45
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
Recommend
More recommend
