Jacques Murray — Notes & Projects

Deliberate Framing: What 20 Years of Photography Taught Me About Software Architecture

· Art· Development

A beginner holding a camera for the first time tries to capture everything in front of them. They see a sprawling city street, lift the camera to eye level, and attempt to cram the entire skyline, the moving traffic, the street vendors, and the clouds into a single frame. The resulting image feels chaotic and indistinct. Every element screams for equal attention, leaving the viewer exhausted and indifferent.

A seasoned photographer approaches the exact same street corner through ruthless elimination. They step forward, wait for the background light to fall into shadow, and frame a single pedestrian stepping through a beam of afternoon sun. The power of the photograph emerges directly from everything the photographer chose to leave outside the frame.

I have spent twenty years making photographs with mechanical cameras, manual prime lenses, and darkroom chemistry. During that same span, I have designed databases, written production backend systems, and architected distributed platforms. Over time, I discovered that these two pursuits share an identical foundational discipline. Great software architecture and compelling visual imagery obey the exact same law: mastery is defined by deliberate subtraction.

The Law of the Frame: Design by Subtraction

When you look through a glass optical viewfinder, the rectangular frame establishes an absolute boundary. Every element included within that boundary must actively support the subject. An extraneous telephone wire cutting across an otherwise pristine sky ruins the composition. You either reposition your feet to eliminate the wire, or you accept a degraded image.

Software engineering suffers from a perpetual temptation toward boundary bloat. When building a new service or class, developers frequently attach secondary capabilities out of speculative convenience. A user service begins by managing identity authentication, and within six months it processes payment webhooks, formats outbound transactional emails, and coordinates background caching queues.

This boundary sprawl parallels a cluttered, undisciplined frame. Every public method, configuration flag, and optional dependency added to an interface increases cognitive burden across the entire engineering team.

In my teardown of why I rebuilt my personal site with Hugo and semantic CSS , I explored how retiring massive JavaScript frameworks in favor of lean static builds produced a dramatic gain in speed and operational clarity. That transition was an exercise in pure framing. By drawing a hard boundary around the required deliverable—pure, fast static HTML—hundreds of unnecessary build dependencies disappeared instantly.

Applying the Law of the Frame to software architecture means treating your API boundaries like the edges of a 35mm negative:

+------------------------------------------------------------------------+
|                          THE ARCHITECTURAL FRAME                       |
+------------------------------------------------------------------------+
|                                                                        |
|   EXTERNAL COMPLEXITY (EXCLUDED OUTSIDE THE BOUNDARY)                  |
|   [ Direct DB Queries ]  [ Vendor SDK Types ]  [ Raw HTTP Payloads ]   |
|                                                                        |
|      ┌──────────────────────────────────────────────────────────┐      |
|      │  ISOLATED MODULE CORE (FOCUSED SUBJECT)                  │      |
|      │                                                          │      |
|      │  • Unified Domain Model                                  │      |
|      │  • Strict, Minimalist Public Interface                  │      |
|      │  • Immutable State Transitions                           │      |
|      │                                                          │      |
|      └──────────────────────────────────────────────────────────┘      |
|                                                                        |
|   INCIDENTAL NOISE (SUPPRESSED THROUGH ABSTRACTION)                    |
|   [ Temporary Cache Files ]  [ Log Serialization ]  [ Tracing ID ]     |
|                                                                        |
+------------------------------------------------------------------------+

Every property exposed on a public contract represents a permanent commitment. Retain only methods that directly advance the core responsibility of that module; crop everything else out.

Negative Space: Protecting the Margin in Interfaces

In classical typography and visual arts, negative space—the empty area surrounding the primary subject—gives an image its balance and legibility. Generous negative space enables human eyes to navigate dense information hierarchies with ease. The void allows the subject to command presence.

In software architecture, negative space represents the decoupling between your systems. It is the breathing room provided by well-defined boundaries, message buses, and asynchronous boundaries.

Tight coupling occurs when developers eliminate architectural negative space. When Module A directly inspects the private internal database tables of Module B to retrieve a single timestamp, the structural margin between them collapses. Any subsequent schema adjustment in Module B breaks Module A, creating an expensive cascade of regressions.

Preserving architectural negative space requires three concrete engineering habits:

  1. Information Hiding: Enforce strict encapsulation. A consuming service should know only what an interface guarantees, remaining completely oblivious to how that data is persisted or computed.
  2. Coarse-Grained Integration Contracts: Design communication interfaces around high-level business events. Passing compact, self-contained payloads preserves distance between services.
  3. Intentional Friction in Dependencies: Resist the urge to import heavy external libraries for trivial utilities. Much like the automated financial workflows I detailed in building a zero-memory financial engine , designing systems around intentional structural boundaries eliminates daily cognitive friction.

The space between your software modules is an active architectural asset. Protect it fiercely.

Lighting Discipline: Illuminating the Critical Path

A photograph is fundamentally a recording of light. Ansel Adams formalized the Zone System to help photographers meter scenes across eleven distinct exposure bands, ranging from pure dynamic black (Zone 0) to pure paper white (Zone X). A successful exposure requires deciding precisely which tonal zones carry the essential detail, allowing secondary backgrounds to fall quietly into shadow.

Every complex software system possesses a critical path—the vital sequence of operations that delivers customer value and guarantees data integrity. In an e-commerce platform, the critical path is authorization, inventory deduction, and payment capture. Background email dispatch, analytics aggregation, and recommendation recalculations are secondary operations.

Architectural failures frequently arise when teams treat every operational path with identical priority:

CRITICAL PATH (ZONE VIII - HIGHEST DETAIL & RECOVERY PRIORITY)
[ Auth Token Verification ] ──► [ Atomic Inventory Lock ] ──► [ Payment Settlement ]

SECONDARY CONCERNS (ZONE III - DECOUPLED BACKGROUND SHADOWS)
                                          │
                                          ▼
                [ Kafka Async Event: Analytics & Metrics Engine ]
                [ Outbox Queue: Customer Confirmation Dispatch ]

When an analytics database experiences latency during a peak transaction window, an undisciplined architecture permits that secondary delay to stall primary customer checkouts. The background clutter ruins the foreground subject.

Lighting discipline in systems engineering demands exposing for the critical path:

  • Synchronous Execution: Reserve synchronous, blocking execution exclusively for atomic data invariants on the core transactional path.
  • Asynchronous Offloading: Push telemetry, message dispatch, and secondary auditing into out-of-band asynchronous worker queues.
  • Graceful Degradation: When secondary subsystems falter, the primary application must continue serving customer transactions with uninterrupted confidence.

Illuminating the essential mechanics while allowing secondary complexity to operate quietly in the background keeps the primary user experience crisp.

The Prime Lens Principle: The Hidden Power of Physical Constraints

A zoom lens promises versatility. By rotating a rubber ring, you can frame a subject at 24mm, 50mm, or 200mm without moving your body. Yet almost every master photographer gravitates toward fixed focal length prime lenses—a single 35mm or 50mm optical element offering a dedicated, unvarying field of view.

Fixed optics introduce severe physical limitations. If you want a tighter portrait, you must walk toward the subject. If you want a wider vista, you must retreat.

This physical constraint transforms your creative process. Working with a single unchangeable perspective builds deep spatial intuition. You learn to read perspective, depth of field, and geometric angles before you even raise the camera to your eye. The constraint forces intentionality.

Software developers enjoy almost limitless resources. Modern cloud instances provide hundreds of gigabytes of RAM, virtually infinite disk capacity, and millions of open-source packages available via a single package manager command.

This boundless abundance often degrades architectural discipline. When memory is practically free, developers tolerate massive memory leaks and oversized bundle sizes. When compute is cheap, algorithms are shipped without performance profiling.

In my post-mortem on running a 9U silent homelab with a Raspberry Pi 5 , I documented how designing services around compact, low-power single-board computers forced cleaner containerization, better backup architectures, and disciplined resource allocations.

Imposing artificial constraints on software development produces superior engineering outcomes:

  • Strict Performance Budgets: Enforce maximum bundle limits (such as 50KB total payload for critical pages) and rigid response latency thresholds (sub-50ms API endpoints).
  • Minimalist Dependency Policies: Require engineering justification before adding any external third-party package to production repositories.
  • Low-Resource Testing: Benchmark services against constrained CPU cores and memory limits to expose inefficient algorithms before deployment.

Operating within strict constraints breeds elegant, resilient software.

The Calibrated Eye: Developing Taste in Engineering Review

In the darkroom, evaluating a photographic print under safe-light illumination requires a calibrated eye. You inspect highlight gradation, shadow contrast, edge sharpness, and chemical grain. Developing that visual sensitivity requires years of deliberate practice and thousands of ruined sheets of silver halide paper.

Reviewing a software Pull Request demands the identical caliber of connoisseurship. A clean PR review extends far beyond verifying that the code compiles and passes automated unit tests.

An experienced engineering reviewer examines the subjective aesthetics of system design:

  • Naming Precision: Do the variable and class names accurately convey their conceptual role within the domain model?
  • Symmetry and Rhythm: Do parallel operations follow consistent structural conventions across the entire codebase?
  • Sensible Boundaries: Has the author introduced an unnecessary layer of indirection that increases cognitive load without delivering tangible isolation?

Taste is the accumulated residue of observing systems fail over decades. It is the quiet instinct that tells an architect a proposed interface feels over-engineered long before production load proves them right.

Building with Intentionality: Five Guiding Axioms

Bridging the craft of photography to software architecture distills into five enduring practices:

  1. Crop Relentlessly: Start every design by identifying what can be removed. The cleanest system is the one with the smallest surface area that still solves the core problem.
  2. Defend Negative Space: Treat the boundaries and decouple margins between modules as first-class architectural components.
  3. Prioritize the Critical Path: Expose your primary business transactions to the brightest light while pushing secondary telemetry into asynchronous background queues.
  4. Embrace Strict Constraints: Limit dependencies, set ruthless performance budgets, and build systems that run smoothly on modest hardware.
  5. Cultivate Architectural Taste: Read code actively. Practice the deliberate craftsmanship that transforms functional scripts into enduring, readable software.

Every line of code you write and every interface you publish represents a deliberate choice. Frame your systems with discipline, subtract the unessential noise, and let the clarity of your core architecture shine.