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 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 5. … 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 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 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 Over time, tune theory to match past observations ● Goal: theory matches future observations ● Refactor theory observations past future How well I understand ≈ How well theory matches future observations
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.
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?
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
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 ● Your patterns (idioms, design, architecture) ● Your styles ● “Programming styles” (Cristina Videira Lopes) ● Responsibility allocation, encapsulation, parsing Mathematical Logic ● Logic, set theory, ● Rare category theory, metamodeling
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, Rarely design patterns, Formalisms and notations UML No Feedback loops Medium Fast (good!)
Today: Developers build models anyway Good news: But: Lots of intellectual curiosity Model building discouraged by ● ● process, done “on the side” Lots of laziness (DRY) ● Not taught directly ● Management tolerates some “slack” ● I.e., “figuring things out” that Social stigma: “Modeling with the ○ ● isn’t immediately delivery door shut” focused
Tomorrow: “Balanced” systems and models Systems and models ready for the next requirement program output past future
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 ●
Recommend
More recommend
