model minded development
play

Model-Minded Development George Fairbanks GOTO Berlin 10 November - PowerPoint PPT Presentation

Model-Minded Development George Fairbanks GOTO Berlin 10 November 2016 1 How does your team build software? 2 How does your team build software? Simple process 1. Get new requirement 2. Write test case 3. Edit code minimally so test


  1. Model-Minded Development George Fairbanks GOTO Berlin 10 November 2016 1

  2. How does your team build software? 2

  3. How does your team build software? Simple process 1. Get new requirement 2. Write test case 3. Edit code minimally so test passes 4. Refactor to remove code duplication 3

  4. How does your team build software? Simple process No models!? 1. Get new requirement 2. Write test case 3. Edit code minimally so test passes 4. Refactor to remove code duplication 4

  5. 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.) ● ... 5

  6. What is Model-Minded Development? It’s the general idea behind many specific ones: Modeling should be a first-class activity in software development 6

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

  8. This talk Main sections: 1. Programming is theory building 2. Programming is distributed cognition 3. What are our software theories / models? 8

  9. Programming is theory building 9

  10. [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 10

  11. 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 11

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

  13. Understanding software Knowing that Knowing how Memorized facts Understanding of the program The Foo module handles reporting Can give impromptu “chalk talk” ● ● It uses Angular 2 about any aspect of the program ● 25k LOC Zooms in or out ● ● Knows what works well vs what is ● No understanding; no theory kluged 13

  14. Theory building in science while (true) { observe world; if (surprise) {refactor theory}; } Refactor the theory observations past future 14

  15. Theory building in science Over time, tune theory to match observations ● Goal: theory matches future observations ● Refactor the theory observations past future How well I understand ≈ How well theory matches future observations 15

  16. Theory building in programming while (true) { pick up new requirement; if (surprise) {refactor theory}; } Refactor the theory requirements past future 16

  17. Theory building in programming Over time, tune program to satisfy requirements ● Goal: avoid “dead ends”, program can always be adapted to next requirement ● Refactor the theory requirements past future 17

  18. Elegant theories are better Worse understanding Better understanding 18

  19. DDD breakthrough Eric Evans, Domain Driven Design, 2004 19

  20. [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. 20

  21. 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. 21

  22. 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 22

  23. Building theories! 23

  24. Programming is distributed cognition 24

  25. Long division ????? ------- 45 | 13095 25

  26. Long division 2?? ------- 45 | 13095 90 -- 40 26

  27. Long division 29? ------- 45 | 13095 90 -- 409 405 --- 4 27

  28. 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 28

  29. Distributed cognition ● Distributed cognition is solving problems with “scribbles on paper” ● It can amplify cognitive ability 29

  30. Distributed cognition ● Distributed cognition is solving ● Programming requires it problems with “scribbles on paper” ○ What size program can you write in your head? ● It can amplify cognitive ability ● Source code is our “scribbles” (our external representation) 30

  31. Internal - external model alignment ????? ------- 45 | 13095 But not just any scribbles 31

  32. Roman numerals, really? ??????? --------- XLV | XIIIXCV 32

  33. Arabic numerals, unhelpful positions 4 3 5 1 0 9 5 33

  34. Misaligned models = poor performance 34 Diagram from Stroop effect, not long division

  35. Fragile magic Distributed cognition is fragile : “ [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 35

  36. You and your scribbles ● It’s a magic trick ○ You + the scribbles ● It is fragile ○ Bad scribbles --> trick fails ● If it’s just you then ○ Use whatever scribbles you want ○ Write whatever code works for you ... what if you are on a team ? 36

  37. Teamwork + external representation 291 ------- Diane Ann 45 | 13095 90 -- Bob 409 405 --- 45 Carl 45 37

  38. How do teams steer ships? 38

  39. Challenges Challenge 1: Internal-external Make sense of external representation ● (charts, logs, …) Challenge 2: Team No one person knows everything ● Team shares external representations ● 39

  40. Success factors Challenge 1: Internal-external Make sense of external representation ● (charts, logs, …) Challenge 2: Team No one person knows everything ● Team shares external representations ● Success requires: Good theories / models ● Good external representations ● Compatible models across team ● 40

  41. Where are we? ● Talked about theory building ○ Parallels between science and programming ● Talked about distributed cognition ○ Can solve bigger problems with a pencil ○ … but only if models align between paper and head ● So … what are our models / theories? 41

  42. Software models / theories 42

  43. 3 categories of models Domain Solution Math, logic, & friends 43

  44. 3 categories of models Domain Solution Math, logic, & friends What your subject matter experts talk about Often: nouns, verbs, and relationships between them Long history in object-oriented programming 44

  45. 3 categories of models Domain Solution Math, logic, & friends What your subject The tech known only by matter experts talk software engineers about Often: nouns, verbs, and ● Design patterns relationships between ● Architecture models them ● Coding styles ● Databases, Long history in event queues, object-oriented data structures programming 45

  46. 3 categories of models Domain Solution Math, logic, & friends What your subject The tech known only by Theories known across matter experts talk software engineers sciences and philosophy about Often: nouns, verbs, and ● Design patterns ● Logic relationships between ● Architecture models ● Set theory them ● Coding styles ● Category theory ● Databases, ● Metamodeling Long history in event queues, object-oriented data structures Libraries in every programming language; core of functional programming 46

  47. If you think it, express it in code Code bridges internal and external ● Code is the “scribbles on paper” Remember: ● Challenge 1: Internal-external ● Challenge 2: Team Keep the magic trick working 47

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend