Remember remember the fifth of November… I certainly do remember the fifth of November—which was last Tuesday. I don’t remember it because of the Gunpowder Plot, certainly not because of the nursery rhyme and at least not today because of V for Vendetta. Rather I once more gave my talk on principle languages. This time as a webcast to Sydney, Australia.

This is also a premiere. This is not the first time for me to present the topic. Neither it is my first webcast or my first presentation in English. But this time I have a recording. And here it is:

(Download)
Slides: Principle Languages (1473 Downloads)

Some general remarks

• Presenting in a foreign language is always a challenge—at least for me. I have to concentrate on language and topic simultaneously. Especially switching languages, i.e. getting into speaking English again, is not easy. So I used some trick to prevent the switch: The talk was 8:15 AM (German time). So as soon as I got up, I started thinking in English. You know, you are in a constant dialog with yourself. You speak with yourself in your head. Normally you do this in your native language. When you really dive into another language (very much reading and/or hearing the other language) you start using that language for your inner conversation with yourself. At first this is a really strange feeling. When I had it the first time I was like „Gosh, I am thinking in a foreign language! Wow!“ It’s kind of weird but really interesting. Over time this somehow looses it’s effect. This time I just forced myself into thinking in English. Of course this doesn’t lead to a „wow“ moment but it was really helpful for the talk.
• My English is not perfect and there were at least three time when I was looking for words. I certainly can still improve on that.
• Especially at the beginning but also sometimes later on, you can hear that I still say „erm“ way too often… It’s difficult to get rid of that.
• When I give a talk I’m not nervous anymore. I don’t suffer from „stage fright“. But hearing the recording I think I can hear some kind of nervousness in my voice. And that changes after a few minutes. So maybe I just learned not to realise my nervousness anymore? I don’t know.
• The second thing that came to my mind when I first listened to the recording was „Blimey, that guy sounds really boring!“ I seem to concentrate so much on language and topic that I cannot make my voice sound less boring. Now I’ve listened to it so much that I don’t realise that anymore—at least not to the extent I felt it the first time. Furthermore I wonder whether I would also have the same feeling when I hear a recording of one of my German talks. I should see if I can manage to get more of my talks recorded. If you have comments on that: Please give me feedback. And please be honest. Although I constantly criticise myself, I certainly don’t need anyone to push my self-confidence. Just be honest and give me feedback.
• All in all I’m pretty satisfied with the talk. Certainly not perfect but OK. I have learned a lot, practiced my English, improved my presentation skills—and it was fun.
• German version of the talk
• More detailed explanations

What’s your verdict? I’d be glad to hear your comments.

Remarks on the talk minute by minute

0:15
– slide 2 // About Me

0:55
– slide 3 // Organizational Stuff

1:48
– slide 4 // Overview

2:39
– slide 6 // Remember remember …
– Maybe I’m not the best actor. 😉 This seems to be a perfect example for how such a start can go wrong. So maybe you can laugh about me failing, instead of laughing about my reference on the fifth of November. Whatever…
==> Note to myself: If you do strange things, practice that

2:53
– slide 7 // once upon a time

3:12
– slide 8 // QBASIC

3:37
– slide 9 // Delphi

3:46
– slide 10

4:05
– slide 11

4:11
– slide 12 // but the code…

4:28
– slide 13

4:41
– slide 14 // BibDB

5:22
– slide 15 // TSystem

6:27
– slide 16 // Diagram

7:07
– slide 17 // Why?

7:31
– slide 18 // Principles

7:36
– slide 19 // Why?

7:43
– slide 20 // How to tell good solutions and bad solutions apart?

7:55
– slide 21 // Analytic
– OK, maybe this is not the best slide; I should have written „Assessment“

9:22
– slide 22 // Some Well-Known Principles
– unfortunately I haven’t translated the slide completely
– „starke Bindung, lose Kopplung“ reads „strong cohesion, loose coupling“
– „Kapselung“ means „encapsulation

10:52
– slide 23 // Principle: Definition

11:53
– slide 24 // „Whatever can go wrong, will go wrong“
– Unfortunately my explanation on the rocket sled project and the origin of ML was incomplete (and not very good anyway). If you are interested in the story behind this principle, have a look at Wikipedia and this article by Nick T Spark.
– As you can see, this is one of the times I had problems here finding the correct words. Of course Murphy’s Law is not actually a story. It’s rather a funny/teasing/tongue-in-cheek comment by Stapp and/or Murphy (nobody really knows who was the first one stating ML).

13:47
– slide 25 // Murphy’s Law (ML)

14:53
– slide 26 // Am example from Java
– there is a typo; of course it should be „an“, not „am“

17:26
– slide 27 // Principles are conflicting

17:55
– slide 28 // sqrt 2
– Pareto Optimum

19:17
– slide 29 // Pareto optimum

24:27
-slide 30 // principle languages

24:35
– slide 31 // How to find suitable principles?

25:03
– slide 32 // Principle Language

25:24
– slide 33 // OOD Principle Language

26:46
– slide 34 // BibDB revisited
– This is another slide where I had some problems finding the right words. You see, my English is far from perfect but I hope it got clear what I meant nevertheless.

28:11
– slide 35 // starting principle

29:57
– slide 36

31:00
– slide 37

31:10
– slide 38
– the light gray bubbles are the principles which have been rules out in the last step. The dark gray principles are considered now. The blue ones are the principles which we already have identified as helpful.

31:45
– slide 39
– The third time I’m looking for words…

32:26
– slide 40

32:38
– slide 41

32:45
– slide 42 // Result
– Maybe I could have stated the judgment a bit better: The simplicity of accessing the other system parts does not justify the liabilities imposed by implicitness and unnecessary coupling.

37:01
– slide 43 // What is better?

37:18
– slide 44 // Dependency injection
– nickhodges.com

37:57
– slide 45 // The Wiki

37:07
– slides 46,47 // www.principles-wiki.net
– here I switched to a browser and showed the wiki directly

42:56
– slide 48 // Advantages

43:12
– slide 49 // Advantages…

44:22
– slide 50 // Learning Design

44:33
– slide 51

45:30
– slide 52

46:24
– slide 53 // Making Design Decisions

46:28
– slide 54

46:44
– slide 55

47:12
– slide 56 // Communication

47:18
– slide 57

47:59
– slide 58

48:32
– slide 59 // Principle Language

48:51
– slide 60 // Conclusion

49:36
– slide 61 // Outlook

50:19
– slide 62 // Thank you, Questions
– Next there are several questions. They haven’t been recorded for technical reasons. On the other hand this enables me to put this recording online without having to ask others for permission.
– In the original recording you would just hear nothing (+ some background noise) for several seconds. As this is not very interesting, I’ve cut that out. The questions (at least as far as I remember) were the following ones:

50:26
– The question here was if the principles are somehow categorized.
– A further remark on this: Besides the categorization of the principles in the OOD Principle Language, in the wiki there is a more coarse-grained categorization. Each principle belongs to one or more „contexts“. The context for the principles in the OOD Principle Language is OOD—object-oriented design. But of course there are principles for other contexts too. And one can also envision principle languages for procedural programming or functional programming, for architecture or coding, for security, performance, usability and so on. So there already is this coarse-grained categorization in the wiki but this is still the beginning and most of the principles in the wiki are concerned with OOD while other contexts are underrepresented.

52:35
– Question (roughly): Which principles should I have a look at to get an overview/a starting base/a minimal helpful subset? Do I have to learn all 19 principles?

54:30
– Question: What happened to BibDB? How did you improve it?
– Remark: Of course the decision on whether to do dependency injection by hand or having a framework do that is also a decision which should be taken deliberately. There are advantages and disadvantages and the principle language can be used to decide which way to go.

57:09
– Question (roughly): First question: (sorry I can’t remember); Second question: Doesn’t the choice of principles depend on the team?
– GoF book
– Note: Of course there are also patterns beside the ones in the GoF book. There are patterns and pattern languages on all levels of abstraction and for a wide range of contexts. This is because there are more than twenty years of research on patterns and—say—just one year of research on principles.
– A Note on DRY: I said that applying DRY imposes further complexity. Some may say this is wrong. DRY reduces complexity. And both statements would be correct. There are situations where applying DRY reduces complexity. Nevertheless the two principles are conflicting. It’s similar to the situation shown at the beginning of the presentation where KISS and GP are conflicting in the choice on how to get the square root of 2. Up to a certain point, the code can be improved according to both principles: DRY and KISS. But then a Pareto-optimum is reached. At the latest when you start writing code generators to get rid of duplication, you certainly start increasing complexity again.
– By „to judge other people’s thinking“ I don’t mean to judge whether they think correctly. Rather you can understand how other people think and make design decisions by figuring out how they wight certain principles.

1:01:28
– Question: The principle language don’t seem to take performance into account.

1:02:48
– Question: For example a reason for using a constant instead of a function call can be, that the function call takes time which might be relevant if it is done very often.

1:03:57
– That’s it; then it’s just thank you and good bye.