Model Minded Development. George Fairbanks SATURN 3 May 2016

Transcription

1 Model Minded Development George Fairbanks SATURN 3 May 2016

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

3 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

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

5 Companies: short and long-term Short-term Cashflow Long-term R&D

6 Software development: short and long-term Short-term Deliver features Long-term Build models This is my gut feel, maybe yours too

7 Example behavior with/without models Without models With models Get new requirement Write test case Edit code minimally so test passes Refactor to remove code duplication Get new requirement Does it challenge our models? a. E.g., client-server still OK? b. E.g., domain model still OK? Revise models Write test case Revise code to match model

8 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

9 Programming is theory building

10 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 other texts. Emphasis added

11 Understanding addition Knowing that Knowing how Memorized facts General theory of addition Know that 3+4=7 Memorize addition table No answers after, eg, 6+6 No understanding; no theory Can add small numbers More mistakes with larger numbers Addition makes numbers bigger Understanding; a theory theory model Gilbert Ryle (1949): Knowing How and Knowing That

12 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?

13 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

14 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

15 What makes a theory valuable? Worse understanding Better understanding

16 DDD breakthrough Eric Evans, Domain Driven Design, 2004

17 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 other texts.

18 Programming without theory building [P]rogramming should be regarded as a production of a program and certain other texts. Every feature we add to this geocentric model makes it harder to add the next feature!

19 Programming is distributed cognition

20 Long division?????

21 Long division 2??

22 Long division 29?

23 Long division

24 Internal-external representations match?????

25 Roman numerals, really???????? XLV XIIIXCV

26 Arabic numerals, unhelpful positions

27 Internal - external model alignment Diagram from Stroop effect, not long division

28 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

29 How do you steer a ship?

30 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

31 Teamwork + external representation Ann Carl 45 Diane Bob

32 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

33 What are our models?

34 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)

35 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

36 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

37 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

38 Yesterday, today, tomorrow

39 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

40 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!)

41 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

42 Tomorrow: Balanced systems and models Systems and models ready for the next requirement program output past future

43 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

44 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

45 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)

46 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