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.

Transcript

1. IN SEARCH OF THE SOFTWARE URSATZ Sean Cribbs @seancribbs
2. ABOUT ME Software Engineer at Basho Technologies We make Riak! erstwhile Pianist, Conductor, Composer, Music Theorist
3. 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
4. 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.
5. A TALE OF TWO PIECES images from Wikimedia Commons
6. A TALE OF TWO PIECES images from Wikimedia Commons
7. A TALE OF TWO PIECES images from Wikimedia Commons
8. 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
9. 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
10. WHO IS HEINRICH SCHENKER?
11. 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
12. 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
13. SCHENKERIAN ANALYSIS & CODE
14. HARMONIC SERIES a.k.a. “The Overtone Series” or “Chord of Nature” images from Wikimedia Commons
15. HARMONIC SERIES a.k.a. “The Overtone Series” or “Chord of Nature” images from Wikimedia Commons
16. HARMONIC SERIES a.k.a. “The Overtone Series” or “Chord of Nature” images from Wikimedia Commons
17. 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.
18. 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
19. 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.
20. 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
21. 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.
22. URSATZ The Fundamental Structure images from Wikimedia Commons
23. URSATZ The Fundamental Structure images from Wikimedia Commons
24. URSATZ The Fundamental Structure images from Wikimedia Commons
25. URSATZ The Fundamental Structure images from Wikimedia Commons
26. URSATZ The Fundamental Structure images from Wikimedia Commons
27. URSATZ The Fundamental Structure images from Wikimedia Commons
28. 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
29. 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.
30. 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
31. GRAPHIC ANALYSIS “Urlinie Tafel” Image from http://nicolas.meeus.free.fr/Analyses.html
32. 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.
33. 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
34. 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
35. EXAMPLE
36. Client App riak_kv_pb_listener riak_kv_pb_server riak_kv_pb_server riak_kv_pb_server riak_kv_pb_server TCP Riak riak-erlang-client
37. 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
38. 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
39. PATTERN ELABORATION gen gen_server riak_api_pb_server
40. PATTERN ELABORATION gen gen_server riak_api_pb_server riak_api_pb_service riak_kv_pb_object
41. PATTERN ELABORATION gen gen_server riak_api_pb_server riak_api_pb_service riak_kv_pb_object Implementation Behaviour
42. REVIEW
43. 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.
44. 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
45. 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
46. THANK YOU @seancribbs