The Cathedral Effect: Designing Engineering Spaces for Creativity and Focus

In software engineering, as in many creative and technical fields, the environment shapes how we think and work. An intriguing psychological phenomenon known as the Cathedral Effect offers valuable insights into how physical and virtual workspaces can be designed to optimize both high-level creativity and detailed execution.

What Is the Cathedral Effect?

The Cathedral Effect reveals how ceiling height influences cognition and behavior. High ceilings evoke a sense of freedom and openness, fostering abstract thinking, creativity, and holistic problem-solving. In contrast, low ceilings create an enclosure that encourages focused, detail-oriented, and analytical work.

Research shows that exposure to high ceilings activates brain regions associated with visuospatial exploration and abstract thought, and confirm that people in high-ceiling environments engage in broader, more creative thinking, while low ceilings prime them for concrete, detail-focused tasks

Applying the Cathedral Effect to Software Engineering

Software development involves both high-level architectural design and detailed coding and testing. The Cathedral Effect suggests that these phases benefit from different environments:

  • High-level work (system architecture, brainstorming, innovation) thrives in “high ceiling” spaces- whether physical rooms with tall ceilings or metaphorical spaces that encourage free-flowing ideas and open discussion.
  • Detailed work (analysis, programming, debugging) benefits from “low ceiling” environments that support concentration, precision, and deep focus.

Matching the workspace to the task helps teams think and perform at their best.

Practical Suggestions for IT Teams and Organizations

Create Dedicated Physical and Virtual Spaces

If possible, design your office with distinct zones:

  • High-ceiling rooms for architects and strategists to collaborate and innovate. These spaces should be open, well-lit, and flexible.
  • Low-ceiling or enclosed rooms for developers and analysts to focus on detailed work without distractions.

For remote or hybrid teams, replicate this by:

  • Holding open, informal video sessions and collaborative whiteboard meetings for high-level ideation.
  • Scheduling “deep work” periods with minimal interruptions, supported by quiet virtual rooms or dedicated communication channels.

Match People to Their Preferred Environments

We should recognize that some team members excel at abstract thinking, while others thrive on details. Assign roles and tasks accordingly, and respect their preferred workspace to maximize productivity and job satisfaction.

Facilitate Transitions Between Modes

Switching between big-picture thinking and detailed work requires mental shifts. Encourage physical or virtual “room changes” to help reset focus and mindset, reducing cognitive fatigue.

Foster Cross-Pollination

While separation is beneficial, occasional collaboration between high-level thinkers and detail-oriented workers ensures ideas remain practical and grounded.

Why This Matters

Ignoring the Cathedral Effect can lead to mismatched environments that stifle creativity or undermine focus. For example, forcing detail-oriented developers into open brainstorming sessions can cause distraction and frustration. Conversely, confining architects to cramped spaces can limit innovation.

By consciously designing workspaces and workflows that respect the Cathedral Effect, organizations can foster both creativity and precision, leading to better software and more engaged teams.

The 4 Eyes Principle

Another principle today.

In the realm of software development, the four-eyes principle dictates that an action can only be executed when it is approved by two individuals, each providing a unique perspective and oversight. This principle is designed to safeguard against errors and misuse, ensuring the integrity and quality of the software.

The four eyes principle can help during the construction of software systems by finding weaknesses in architecture, design or code and can help to improve the quality. In every phase of the software development cycle, this principle can be applied, from the requirements analysis phase to the detailed coding phase.

Software architecture, design, and code could be co-developed by two people or peer-reviewed.

In the design of software systems, the four-eye principle applies to the process of validating design decisions on various levels. Pair programming is a software development technique in which two programmers work together on code, one usually doing the coding and the other doing the validation. In other engineering industries, dual or duplicate inspection is a common practice.

In regulated environments such as Financial Institutions, compliance requirements may dictate that code is always peer-reviewed to prevent backdoors in code.

In software systems itself, the four-eyes principles may be implemented when supporting business processes requiring this for security or quality validation reasons.

Change management, a critical aspect of software development, often relies on the four-eyes principle. When code changes are transitioned into production, a formal change board may mandate a signed-off peer review, ensuring that all changes meet the required standards. Change and Configuration Management tools for software systems are often designed to support this four-eyes principle process, further enhancing the quality and security of the production environment.

Further assurance can be added by adding a (random) rotation scheme of authorized individuals to serve as the second pair of eyes. This may provide additional assurance as it will not be known beforehand which two individuals will be dealing with a given decision.

Related / similar: Dual Inspection, Code Review.

Noise reduction

The principle of noise reduction in software systems improves software systems by removing inessential parts and options and/or making them invisible or only visible to selected users.

Reducing the options in a software solution increases usability. This goes for user interfaces as well as technical interfaces. We decide what an interface looks like and stick to it. All-too-famous examples of noise reduction are the Apple iPod and the Google search page.

Adding features for selected users means adding features and under-the-hood complexities for all clients.

Reducing options also makes the software more robust. If we build fewer interfaces, we can improve them. We can focus on really doing well with the limited set of interfaces.

In practice, we see hardware and software tools have many options and features. That is not because software suppliers desperately want to give their customers all the options but because we, their customers, are requesting these options. Software suppliers may view all these requests more critically. Some do.

Let’s aim to settle for less. We shouldn’t build more every time we can do with less just because we can. Also, we shouldn’t ask our suppliers to create features that are nice to have.

There are always more options, but let’s limit the options to 4 or better: 1.

Hypes

Some companies have made a business model out of technology hypes. These are the same companies that tell the market what it needs by asking the market. Of course, this comes with an invoice mentioning generous compensation. These companies write classy reports with colorful graphics in which they advise organizations to do what the organizations tell them to do.

But hypes are for techies. Techies may feast on technology, but for organizations, jumping on hypes can be a risky and costly pastime.

There are two types of hypes. Hypes can be about something new. Other hypes are just reformulations of existing things, recycled ideas.

But hypes are hypes: they will go away. The vast majority of hypes disappear into thin air. The techie may have learned from them. Some remain. It might be valuable if a technology is still around after a few years. But usually, the stuff will not be as groundbreaking and revolutionary as predicted when announced by the hype cycle company, that is, by the market itself.

Blockchain, anyone?

Some hypes are recycled ideas. We have no memory, and we don’t read textbooks. SOA, AI, microservices, and technical advancements are wrapped in shiny new names and gift papers, so they appear to be a gift from your software supplier or consultancy company.

Think Globally, Act Locally applied to IT

Solution architects should consider the enterprise impact of architectural decisions.

Solution architects must ignore enterprise directions if these lead to local inefficiencies or have other predominantly negative local effects.

There is a significant difference between the clean 30000-foot view (sometimes referred to as the air castle) and the muddy reality on sea level.

Gear Acquisition Syndrome

Photographers tend to suffer from Gear Acquisition Syndrome. They believe they will make better pictures with new gear and buy new lenses, cameras, and flashlights.

Then they find their work does not improve.

In IT, we do the same.

We have our old relational database management system.

But now we have this great Spark, MongoDB, CouchDB, or what have you. (I’m just taking a not-so-random example.) So now everything must be converted to Spark or Mongo.

We even forget that this old technology, the relational DBMS in this example, was so good at reliably processing transactions. It worked!

The new database is massively scalable, which is great. Unfortunately, it does not improve the reliability of processing our transactions.

But it’s hot, so we want it—because Google has it. Errr, but will you also use it to process web page indexes? Ah, no. You want to store your customer records in it. So, is it reliable? No. But it is satisfying our GAS.

Aesthetics and quality

Beautiful things are easier to use.

We can also apply this to technical designs. This often surprises a non-technical audience, but techies will recognize the beauty that can be present in technical solutions.

For example, symmetrical diagrams not only give a quick insight into an orderly, robust solution but are often also very appealing to the eye.

Symmetrical and well-colored diagrams are easier to read and understand.

Old PowerPoint presentations using the standard suggested colors were horrendously ugly, and I am sure the people using these colors did not want to be understood. (Nowadays, PowerPoint comes with more pleasing color schemes)

The success of the Python programming language is not in the least its forced readability. No crazy abbreviations as in C that make code unreadable (but programmers look very smart).

Beautiful code (yes, such a thing exists) is easier to read and understand.


If a
Then b
Else  If c
      Then d
      Else  If e
              Then f
…

versus


Case a
 b
Case c
 d
Case e
 f
…


It is pretty evident.

But do we care about the quality and beauty of code nowadays? Throw-away software is abundant. Software systems are built with the idea to throw them out and replace them within a few years.

Ursus Wehrli
Image by Ursus Wehrli

That is the idea. But the Lindy effect tells us differently.

Good programming is a profession that should be appreciated as such. Bad coding may be cheap, but only in the short run.

We don’t hire a moonlighter to build our house. We employ an architect and a construction professional who can make a comfortable house that can be used for generations.

Abstraction

The abstraction principle in software systems allows us to create more generically usable software components.

Abstraction removes details from the problem space and thus makes it easier to think about problems and solutions. This principle lets us focus on problems by reducing complexity.

Abstraction makes software components more reusable: code for specific problems is abstracted to code that applies to a broader class of problems.

The process of abstraction, or generalization, removes specific attributes or functions and replaces these with general counterparts. The abstract components can be made specific through parameters or inheritance.

Abstraction is also a modeling technique that allows logical grouping of software structures so they can be better designed, realized, and maintained. Through this grouping, a complex software solution is methodically chopped up into smaller pieces that can be handled better in all phases of a software system lifecycle.

Examples of abstraction in software systems:

The OSI networking model abstracts communication protocols in functional layers.

Messaging middleware solutions abstract the connectivity logic from the application.

Picasso’s bull

The 80/20 principle

The 80/20 principle also known as the Pareto principle applies to many areas.

The most common application of the principle is in the assessment of a project effort: 20% of the effort produces 80% of the job to be do done. Or the other way around, the last 20% of the work to be done will take 80% of the effort.

In IT, the principle applies also similarly to requirements versus functionality: 20% of the requirements determine 80 procent of the architecture. 20% of the requirements are the important ones for the core construction of a solution.

The principe thus tells you to focus on the 20% important requirements that determine the architecture. It helps you shrink the options you need to consider and prioritize and focus on the important parts of the solution.

The question is of course: which of the requirements are the important ones. The experience of the architect helps here. But in general you will realize while analysing requirements, if a requirement will need a significant change or addition to the solution.

A good book about the 80/20 principle is the book with the same name: The 80/20 Principle, by Richard Koch.

An example from an practitioner architecting an airline reservation system.

“The first time I (unconsciously) applied the 80/20 rule was in my early days as an architect. I was working with a team of architects on application infrastructure for completely new web applications. A wide variety of applications were planned to run on this infrastructure. However, it was not clear yet what the characteristics, the volumes, response time needs, concurrent users et cetera were for these applications, and that made it uncertain what we needed to cater for in this generic hosting solution.

So we decided to walk through the known use cases for the different applications.

We worked our way through four of the tens of applications. During the fourth we somehow could not come up with additional requirements for the application infrastructure. We realized that the rest of the set of applications would ‘only’ be a variety of one of the apps wealready looked at. So we had our 80% from looking at just 20%.”