Dimensions of Software Excellence

As a follow up to our first article on Bridges Summit, that captures key insights from software industry and research community discussions, this article expands on the topic to focus on the challenges of achieving Software Excellence.  At our first Bridges Summit, we brought together thought leaders from research and software industry communities to explore a bold question: Is developer productivity really the right goal?  In a collaborative discussion, community members gathered around virtual tables, brainstorming ideas on sticky notes to clarify the vision of what we’re truly aiming for. 

As a starting point for discussion, we introduced the Bridges Triangle, connecting three lenses: Developer Experience, Software Excellence, and Thriving. Two of these lenses—Experience and Thriving—invite us to look inward, examining how we work and our overall well-being.  But something was missing.  What about the thing we're building?

Bridges Triangle of three lenses reframing the goal: Developer Experience, Software Excellence, and Thriving

That missing lens came into focus when we came across Eric Normand’s article, A Hypothesis About Software Excellence.  In it, Eric reflects on his own experiences across different companies and draws a compelling contrast.   When his teams were most successful, developers spent time exploring the core ideas of the business— actively searching for the foundational concepts that give the software meaning, and shaping how those ideas are expressed in code.   This kind of work is creative and conceptual: it involves collaborating with business stakeholders not just to gather requirements, but to co-discover and refine the mental models behind the product.

By contrast, when Eric’s teams were least successful, infrastructure was king: endless tinkering with deployment tools, AWS services, and message queues—often disconnected from the software’s purpose.  Eric isn’t dismissing infrastructure; he sees it as essential, but ideally simple and in the background, freeing up time to focus on creating business value.  He proposes a hypothesis: developers who spend more time exploring business concepts will achieve higher levels of software excellence.  While this hypothesis is not yet validated, it opens the door to a new paradigm of measurement—one based not only on velocity or the volume of output, but on the depth of engagement with the ideas behind the software.

Eric Normand's hypothesis: developers who spend more time exploring business concepts will achieve higher levels of software excellence. 

At the summit, we invited community members to reflect and discuss the lens of Software Excellence, and identify problems and constraints that prevent us from building meaningful products and doing high-quality work.   What emerged was a rich and nuanced view of Software Excellence that is multidimensional, encompassing not only the quality of the code and infrastructure, but also the clarity, relevance, and impact of the product itself.  We summarized the problems and constraints into three themes, which we discuss next.

Theme 1: Excellence Requires Shared Purpose: Fit for What, and for Whom?

One of the key themes to emerge from the community was that software excellence requires shared purpose. Marian Petre also highlighted the central importance of shared purpose with her research on high-performing teams, that through a shared caring about the product and building a product fit for purpose, the team aligns around a shared sense of what matters.  Community members shared how the “why” behind the work was unclear— there wasn’t enough business context to understand why the developers were building what they were building, and for whom.  The developers lacked an understanding of how the product aligned with business goals, and what business priorities were around things like security or time to market.  Others pointed out the absence of regular dialogue between teams and business leaders, leading to a disconnect about the broader vision of what success even looks like.  

Through a shared caring about the product and building a product fit for purpose, the team aligns around a shared sense of what matters. 

Community members also brought up different types of excellence, which lead to misalignment around goals.  For example, excellence in software engineering is different than excellence in the solution space of the product.  As one community member put it, “geek excellence isn’t business excellence.” One community member highlighted that we don’t really know whether our product is excellent or not until we ship it, and any pre-release ideas about it’s excellence are subjective.  While these different dimensions of excellence aren’t inherently at odds, it’s important to have dialogues that consider all the dimensions of excellence we’re aiming for, to bring the teams and business leaders into better alignment.

Even with the intention of shared purpose, uncovering the real needs of customers to be able to build a product fit for purpose, is still challenging and takes effort.  Community members talked about building “solutions looking for problems”, rather than having a good understanding of the customer’s problems.  In some environments, there was no appreciation for how the product was used. Software teams easily get stuck in a feature factory mindset, focusing on delivering features disconnected from purpose, rather than delivering value to customers.  Cultivating shared purpose also requires effort to connect with the customers.

Theme 2: Software is a Living System: People, Knowledge, and Sustainability

The second theme focused on the challenges of software excellence from the perspective of the broader ecosystem: that software is not just code—it is a living system of people and knowledge that has to be sustained through time.  Community members spoke to invisible forms of decay—lost knowledge about the systems and domain, neglected maintenance, and organizational forgetting.  The knowledge of how to maintain the software needs to be sustained over time, even as developers join and leave the company.  Developers new to the codebase and frameworks need time to learn, and time for training.  Policy decisions around hiring also impact the software’s sustainability.  For example, when developers have short tenures it leads to short-term solutions being incentivized, followed by the knowledge for how to maintain the software, walking out the door.

Community members spoke to invisible forms of decay—lost knowledge about the systems and domain, neglected maintenance, and organizational forgetting.

Community members highlighted how fragile the system can become under the constant business pressure to deliver features, when knowledge continuity is broken, when learning time is under-supported, and sustainability isn’t kept in mind.  There’s always the legacy of the existing code in all it’s complexity.  Community members highlighted how the cost required to maintain existing software was typically underestimated, and how hard it was to prioritize sustainability and maintenance over new features.  Members also discussed how critical automation is in the software development lifecycle, that having a reliable deployment pipeline that doesn’t block or slow down releases, is key to ensuring the work gets pushed out.

Theme 3: Excellence Emerges Through Intentional Engagement and Feedback Loops

The third theme centered around how excellence actually comes into being—not as a checklist or predefined outcome, but as something that emerges through ongoing dialogue, reflection, and feedback.  Community members highlighted how most organizations weren’t optimized for learning, and long or broken feedback loops were the norm.  For example, when strategic decisions get made upstream and engineers or designers are brought into discussions late in the process, it can be difficult to change course and make corrections.   The nature of software work usually requires lots of communication, continual adjustment, and iteration, making feedback loops an important part of the equation.

Feedback loops don’t just appear on their own, we have to intentionally make space for feedback to happen.  Community members discussed how the feedback loops with customers break down because we don’t make space for them to happen.  When engagement with customers is sporadic, shallow, or missing altogether, it's difficult to know whether the software is actually solving the right problems.  There’s a need for ample user feedback from customers that is quality and actionable.  There also needs to be time to process the feedback, and space for reflection and creative thinking to happen, ideating on ways to do better.   Software excellence is multidisciplinary, and requires multiple perspectives involved.  

Feedback loops don’t just appear on their own, we have to intentionally make space for feedback to happen. 

Software excellence is less about perfection and more about process. It’s about creating the conditions where learning is possible—where cross-functional voices are included early, where feedback is sought and integrated, and where teams have the time and permission to reflect. Excellence is not just what we build, but how we stay in conversation with it.

Closing Reflection

Taken together, these three themes reveal a more nuanced and human view of software excellence—one that reaches far beyond technical metrics or abstract ideals. Excellence, as described by the community, is not a static quality to be achieved once and for all. It takes shape through shared purpose, continuity of knowledge, and intentional structures for reflection and feedback. It depends not just on what we build, but on how—and with whom—we build it.

In revisiting Eric Normand’s hypothesis, we see its resonance echoed across these dimensions. Community members didn’t just call for better infrastructure and code quality—they called for deeper engagement with the meaning behind the product, and with the people affected by it. What emerged was not a singular definition of software excellence, but a set of interdependent dimensions: fit for purpose, sustainability, and deep engagement. As our triangle of lenses suggests, Software Excellence doesn’t stand alone—it lives in relation to Developer Experience and Thriving.  In our next article, we’ll turn to the third lens in the Bridges Triangle, and explore what it means for individuals, teams, and organizations to thrive.