Upgrade to Pro — share decks privately, control downloads, hide ads and more …

In Search of the Software Ursatz

Sean Cribbs
February 26, 2014

In Search of the Software Ursatz

What are the building blocks of our software systems? Why does a program in an object-oriented language feel so different from an equivalent one in a functional language? How do the design decisions in one part of our code affect the other parts? What makes software well- or poorly-designed? To answer these questions, I turn to the work of Heinrich Schenker, a 19th-century-born musician who is best known for his theories of musical analysis. Those theories claim that the works of composers like Bach, Mozart, Beethoven, and Brahms could be peeled away, like the layers of an onion, to discover the Ursatz -- or fundamental structure -- that underlies all "great" (in his mind) Western art music. The process of peeling those layers reveals to the analyst how each composition manages to be written in the same "language" as the others, but feel unique on the surface. Schenker's ideas about structure and analysis are still actively studied by music scholars and even applied to musical styles that are very different from his focus. In this talk I'll briefly introduce Schenker's musical theories and then apply the layered analysis technique to some interesting software systems, going beyond surface aesthetics to discover their Ursatz. Along the way we'll discover intricate internal relationships and perhaps be able to quantify a what makes a good software design.

Sean Cribbs

February 26, 2014
Tweet

More Decks by Sean Cribbs

Other Decks in Programming

Transcript

  1. ABOUT ME Software Engineer at Basho Technologies We make Riak!

    erstwhile Pianist, Conductor, Composer, Music Theorist
  2. IN SEARCH OF... An understanding of so!ware cra!smanship An intuitive

    technique for analysis of software structure A subjective means of critical comparison More why and less how
  3. WHY CARE? We can improve our cra!, so we need

    a "amework for critical thought that goes beyond surface features. There is a difference between simplicity and ease. My belief: Systems reflect [leak?] the foundations on which they are built.
  4. A TALE OF TWO PIECES J.S. Bach’s Prelude No. 1

    in C and Chopin’s Etude No. 8 in F images from Wikimedia Commons
  5. A TALE OF TWO PIECES J.S. Bach’s Prelude No. 1

    in C and Chopin’s Etude No. 8 in F Have the SAME Fundamental Structure images from Wikimedia Commons
  6. BIOGRAPHICAL Born 1868 in present-day Ukraine Studied as a child

    with Carl Mikuli in Lemberg (Lviv) Scholarship to University of Vienna in 1884, also studied at the Konservatorium with Anton Bruckner & Ernst Ludwig Became regular performer, conductor, composer, critic, and theorist Taught his theories privately in his home
  7. ACCOMPLISHMENTS Championed Urtext and the study of primary sources: manuscripts,

    diaries, letters Published extensive scholarly editions of major works, incl. Beethoven’s Symphony no. 9 Theories of Harmony, Counterpoint, and Free Composition
  8. VERTICAL IN CODE The environments in which our software runs

    – hardware, operating system, runtime, libraries – constitute the vertical dimension or harmony. Each component in the vertical is built on a layer below, imparting some of that layer’s aesthetics and form up the stack.
  9. COUNTERPOINT The interaction of two or more simultaneous melodic lines,

    aka “voice leading” Counterpoint “rules” derived from intervallic relationships, aesthetic considerations Strict: regular divisions of other line aka “species” Free: free choice of all/any divisions, chromaticism, freer dissonances
  10. HORIZONTAL IN CODE Linear progressions of steps in code are

    analogous to melody. Interactions and tensions between independent procedures constitute a sort of counterpoint. Procedures in lock-step are like strict counterpoint; procedures with independence are more free and pleasing.
  11. DER TONWILLE “The Will of the Tones”, or Scale Functions

    images from Wikimedia Commons 1 2 3 4 5 6 7 8 1 - tonic 2 - dissonant, down 3 - consonant 4 - dissonant, down 5 - consonant 6 - consonant, down 7 - dissonant, up 8 - consonant
  12. WILL OF THE CODE Coupling and connascence are analogous to

    notions of consonance, dissonance, and scale function. Removing coupling resolves unnecessary dissonance. Reducing the degree of connascence produces more harmonious, flexible, modular code. The relationships of independent procedures should point toward the same goal.
  13. PROLONGATION “Semper idem sed non eodom modo” Always the same,

    but not always in the same way. The process of composing-out [Auskomponierung]: extending a harmony over time, or elaboration The exploration of the meanings of a motif Gives rise to different structural levels (Schichte) Progression from strict to "ee counterpoint
  14. CODE PROLONGATION Refactoring toward general algorithms is analogous to structural

    prolongation in music. Use of generalized algorithms [patterns?] increases readability and maintainability, and can be more amenable to global optimization.
  15. CODE COMPLEXITY “Most techniques for controlling compleixty...decompose a problem into

    almost independently solvable subproblems” “[A] good package encapsulates a higher level concept which has meaning independent of its implementation.” “Often one can make progress to the solution of a simplified version of the problem which is similar in some essential aspect to the original one but which differs from it in detail.” – Sussman and Steele, The Art of the Interpreter
  16. CODE GRAPHS? We have no strong analogy here: boxes-and-arrows, sequence

    diagrams, UML, etc, are all in a vocabulary different "om the subject being analyzed. On the other hand, we%-structured code could approach its own graphical analysis.
  17. KEY POINTS A unique understanding of harmony and counterpoint Relies

    on the intuition and subjectivity of the musician Multiple, interrelated layers of structure via prolongation A common language independent of style
  18. LIMITATIONS Focused on Tonal music only, expanded later by others

    Plagued with 19th-century chauvinism, disregards unprivileged viewpoints Predates modernist and post-modernist art and theory
  19. PROBLEMS Client library is a dependency of the server Hard

    to extend server process with new requests, coupled to Riak KV Request processing intermixed with connection handling
  20. DECOUPLING Separate request/response message definition into an independent library Separate

    connection management from request processing, using Erlang “behaviours” - basically creating a uniform interface Extract the new structure from Riak KV into a new namespace/app
  21. REVIEW Software and music are multi-layered with intricate internal relationships.

    Our cra! of software should reflect an intuition and awareness of multiple simultaneous levels of abstraction. We are both composer and analyst. This analytical technique does not prove greatness or correctness, but could be a means for greater insight into software design.
  22. REFERENCES Schenker, Heinrich; ed. and annot. Oswald Jonas (1954) [1906].

    Harmony. trans. Elisabeth Mann-Borgese. Chicago: University of Chicago Press. ISBN 0-226-73734-9. OCLC 280916. Schenker, Heinrich. Five Graphic Music Analyses. Dover, 1969. SchenkerGUIDE http://www.schenkerguide.com Schenkerian analysis on Wikipedia: http://en.wikipedia.org/wiki/Schenkerian_analysis
  23. REFERENCES, CONT. Luciane Beduschi and Nicolas Meeùs. Schenkerian Theory and

    Analysis http://nicolas.meeus.free.fr/Analyses.html Steele, Guy and Sussman, Gerald. The Art of the Interpreter. MIT AI memo No. 453, 1978. ftp://publications.ai.mit.edu/ ai-publications/pdf/AIM-453.pdf