The Illuminating Engineering Society has a couple interviews with Kim and Paul Mercier, authors of a book called Architecture for Light. The content is fascinating, touching on anthropology, physics, engineering, design and their professional experience, but a few things stood out to me in particular as overlapping with software engineering:
- The role of people
- Efficiency
- Multi-disciplinary planning
People
Perhaps the connection to people is more immediate in the field of lighting design than software engineering, but the two have a couple things in common that can negatively affect usability: creative purity and cost efficiency.
In software and architecture, we can design something that’s aesthetically pure, but difficult to incorporate or maintain.
One of the best tools I’ve found in project management is a focus on the customer. This can help us prioritize and avoid ethical pitfalls.
Related, healthy organizations recognize software is built by people, and people thrive in a nurturing environment. For example, Google’s research indicated psychological safety correlated strongly with high-performing teams.
Efficiency
The Merciers describe an approach to lighting that minimizes electrical usage and maximizes sales, but focusing light on products. (A common alternative is to uniformly light a space.)
They mentioned the most cost-effective solution is to turn the lights off. This reminds me of a balance in software engineering: we need to maintain everything we build, so not building minimizes maintenance cost. A similar balance comes up in SRE: we can maximize stability by minimizing changes. Obviously, doing nothing has other costs, but having all options on the table opens up opportunities, such as only invest light where a customer’s attention produces value.
The Merciers propose a method that maximizes efficiency and usability. This was an amazing observation: not too long ago, daylight was the most efficient light source; it’s still very efficient, but we need to rediscover the skills to use it.
Multi-disciplinary planning
The Merciers recommend including lighting designers from the “imagination” phase of a project rather than pulling them in later. Lighting designers can then advise on structural changes to maximize lighting efficiency. They describe the opposite as an anti-pattern: bringing specialists in late to fix problems.
This reminds me of a tension when organizing software development teams: a “waterfall” model where each specialty contributes in sequence, versus an “agile” model where teams are composed of cross-functional members.
They describe several examples in their interview, but one reminded me of complex workarounds that can arise in software: a building design that let in too much daylight. They observed a small overhang would be ideal, but because the design was already finalized the building had to be outfitted with a mechanical shade.
A software engineering toolkit 🛠 