to Artful Design • Chapter 4: “Programmability & Sound Design”
Nicholas Shaheed
October 23, 2022
Music 256A / CS476a, Stanford University
For this week’s reading, I will be responding to Principle 4.3 and Principle 4.4 from the fourth chapter of Artful Design, which state:
Principal 4.3: Build Complexity as the sum of simple elements
Principal 4.4:
Local Independence - Each element can change on its own
Global Coordination - All elements subject to a larger organizing principle
For my response on these two principles, I’m mostly channeling my experience with software development, making music with code, and how I think making software can be really different when you do it for a creative project versus in a professional setting, where you’re building something with a team.
A key difference that I’ve noticed is the role exploration plays when making a creative work using code. You don’t necessarily start out with a plan (or, if you do, you have a plan that can change rapidly). This has a pretty profound influence on how a codebase develops. In my experience with software, a huge portion of the structure and architecture of the code is decided before any code is written. This is probably not true everywhere, but when working with big enterprise products with lots of stakeholders, it becomes a high priority to agree on both the requirements and figure out what the code is going to look like as early as possible. This means both having clearly defined features (because prioritizing engineering time is important) and figuring out what actually needs to be built is important (both because engineering time is costly, but also because unnecessary code complexity can have long-standing effects further down the line). In a sense, Principle 4.3 is not relevant to enterprise software - everything tends to be really top down.
Principal 4.4, specifically the part about global coordination, is where the two worlds really diverge. Global state is usually a Bad Thing in software - it introduces a lot of opportunities for system to talk to each other in ways that are hard to reason about and a lot of thought and effort is usually put into designing software in a way that isolates the different parts of it so that only the things that absolutely need to talk to each other are able to. In my experience (which lines up with Principal 4.4) is that a certain amount of global state is not only okay, it’s essential for being creative with your code. At least for me, different systems being able to talk to each other is really important, because that’s where a lot of the interesting ideas come from.