Interesting Talk: "Rethinking All Practices: Building Applications in Elm"

I've just watched this great talk by Jamison Dance

• Rethinking All Practices: Building Applications in Elm

Interesting Talk: "Beyond Continuous Improvement"

I've just watched this wonderful short talk by Russell L. Ackoff

• Beyond Continuous Improvement

Books I read (January - August 2017)

January
- Vencidos pero vivos (Vaincus mais vivants), Maximilien Leroy and Loïc Locatelli Kournwsky
- El Boxeador: la verdadera historia de Hertzko Haft (Der Boxer: Die Überlebensgeschichte des Hertzko Haft), Reinhard Kleist
- Vuelo a casa y otras historias (Flying Home and Other Stories), Ralph Ellison
- Rendezvous with Rama, Arthur C. Clarke
- Treasure Island, Robert Louis Stevenson
- Agile Principles, Patterns, and Practices in C#, Robert C. Martin
- Atonement, Ian McEwan
- En una piel de león (In the Skin of a Lion), Michael Ondaatje

February
- El gigante enterrado, Kazuo Ishiguro
- The Time Machine, H.G. Wells

March
- JavaScript Patterns: Build Better Applications with Coding and Design Patterns, Stoyan Stefanov
- Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, Tom DeMarco
- El minotauro global (The Global Minotaur: America, the True Origins of the Financial Crisis and the Future of the World Economy 2nd edition), Yanis Varoufakis
- La sonrisa etrusca, José Luis Sampedro

April
- Howards End, E. M. Forster
- A Wizard of Earthsea, Ursula K. Le Guin
- Las tumbas de Atuan (The Tombs of Atuan), Ursula K. Le Guin
- En tierras bajas (Niederungen), Herta Müller
- How to Love, Thich Nhat Hanh
- La costa más lejana (The Farthest Shore), Ursula K. Le Guin
- Tehanu, Ursula K. Le Guin
- Obliquity: Why our goals are best achieved indirectly, John Kay
- Tales from Earthsea, Ursula K. Le Guin
- The Other Wind, Ursula K. Le Guin
- Metaphors We Live By, George Lakoff and Mark Johnson

May
- Are Your Lights On? How to Figure Out What the Problem Really Is, Gerald M. Weinberg, Donald C. Gause
- Bird by Bird: Some Instructions on Writing and Life, Anne Lamott
- Nonviolent Communication: A Language of Life, Marshall B. Rosenberg
- Mañana. Una revolución en marcha (Demain. Un nouveau monde en marche), Cyril Dion
- Thinking in Systems: A Primer, Donella H. Meadows, Diana Wright

June
- So Good They Can’t Ignore You, Cal Newport
- The Man Who Would Be King, Rudyard Kipling
- A Few Lessons From Sherlock Holmes, Peter Bevelin
- El dios de las pequeñas cosas (The God of Small Things), Arundhati Roy (2nd time)
- What Did You Say?: The Art of Giving and Receiving Feedback, C. N. Seashore, G. M. Weinberg, E. W. Seashore

July
- Pride and Prejudice, Jane Austen
- La Meta (The Goal), Eliyahu M. Goldratt
- Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, Edward Yourdon and Larry L. Constantine
- The Tartar Steppe (Il deserto dei Tartari), Dino Buzzati
- Getting It Done: How to Lead When You're Not in Charge, Roger Fisher, Alan Sharp
- Humble Inquiry: The Gentle Art of Asking Instead of Telling, Edgar H. Schein
- Occupy, Noam Chomsky

August
- Sinuhé, el egipcio (Sinuhe egyptiläinen), Mika Waltari (2nd time)
- La mejor oferta (La Migliore Offerta), Giuseppe Tornatore
- Programming Beyond Practices, Gregory T. Brown
- Clojure Polymorphism, Paul Stadig
- Why Don't We Learn from History?, B. H. Liddell Hart
- Usable Software Design, Alexandru Bolboaca
- Decline and Fall, Evelyn Waugh
- La Casa Infernal (Hell House), Richard Matheson

Interesting Talk: "Beyond PEP 8, Best practices for beautiful intelligible code"

I've just watched this great talk by Raymond Hettinger

• Beyond PEP 8, Best practices for beautiful intelligible code

Notes on OCP from Agile Principles, Practices and Patterns book

This post continues with the series of posts publishing my notes about SOLID principles taken from Robert C. Martin's wonderful Agile Principles, Practices and Patterns in C# book.

• OCP -> "Software entities (classes, modules, functions, etc) should be open for extension but closed for modification <- [Martin's definition. The origin of the principle comes from Bertrand Meyer that gave it a slightly different definition]"
• "When a single change to a program results in a cascade of changes to dependent modules, the design smells of fragility" <- [related with violating Beck's Local Consequences principle from Implementation Patterns] OCP advises us to refactor the system so that further changes of that kind will not cause more modifications. <- [related with Cockburn's & Larman's Protected Variations] If OCP is applied well, further changes of that kind are achieved by adding new code, not by changing old code that already works"
• "It's possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors"
• "[A module that uses such abstractions] can be closed for modification, since it depends on an abstraction that is fixed. Yet the behavior of the module can be extended by creating new derivatives of the abstraction"
• "Abstract classes are more closely associated to their clients than to the classes that implement them" <- [related with Separated Interface from Fowler's P of EAA book]
• "[Strategy and Template Method patterns] are the most common ways to satisfy OCP. They represent a clear separation of generic functionality from the detailed implementation of that functionality"
• Anticipation
  • "[When a] program conforms to OCP. It is changed by adding code rather than by changing existing code"
  • "In general no matter how "closed" a module is, there will always be some kind of change against which it is not closed"
  • "Since closure can't be complete, it must be strategic. That is the designer must choose the kinds of changes against which to close the design, must guess at the kinds of changes that are most likely, and then construct abstractions to protect against those changes."
  • "This is not easy. It amounts to making educated guesses about the likely kinds of changes that the application will suffer over time."
  • "Also conforming to OCP is expensive. It takes development time and money to create the appropriate abstractions. These abstractions also increase the complexity of the software design"
  • "We want to limit the application of OCP to changes that are likely"
  • "How do we know which changes are likely? We do the appropriate research, we ask the appropriate questions, and we use or experience and common sense. And after all that, we wait until the changes happen!" <- [relates with Yagni, also talking about learning about your domain] "We don't want to load the design with lots of unnecessary abstractions. <- [related with Metz's The Wrong Abstraction] Rather we want to wait until we need the abstraction and then put them in"
• "Fool me once"
  • "... we initially write our code expecting it not to change. When a change occurs, we implement the abstractions that protect us from future changes of that kind."
  • "If we decide to take the first bullet, it is to our advantage to get the bullets flying early and frequently. We want to know what changes are likely before we are very far down the development path. The longer we wait to find out what kind of changes are likely, the more difficult it will be to create the appropriate abstractions."
  • "Therefore, we need to stimulate changes"
    • "We write test first" -> "testing is one kind of usage of the system. By writing tests first, we force the system to be testable. Therefore, changes in testability will not surprise us later. We will have built the abstractions that make the system testable. We are likely to find that many of these abstractions will protect us from other kinds of changes later <- [related with Feather's The Deep Synergy Between Testability and Good Design]."
    • "We use short development cycles"
    • "We develop features before infrastructure and frequently show those features to stake-holders"
    • "We develop the most important features first"
    • "We release the software early and often"
• "Closure is based on abstraction"
• "Using a data-driven approach to achieve closure"
• "If we must close the derivatives [...] from knowledge of one another, we can use a table-driven approach"
• "The only item that is not closed against [the rule that involves] the various derivatives is the table itself. An that table can be placed in its own module, separated from all the other modules, so that changes to it do not affect any of the other modules"
• "In many ways the OCP is at the heart of OOD."
• "Yet conformance to [OCP] is not achieved by using and OOP language. Nor is it a good idea to apply rampant abstraction to every part of the application. Rather it requires a dedication on the part of the developers to apply abstraction only to those parts of the program that exhibit frequent change."
• "Resisting premature abstraction is as important as abstraction itself <- [related with Metz's The Wrong Abstraction]"

Other posts in this series:

• Notes on SRP from Agile Principles, Practices and Patterns book