Third part of the series on quality in Lean Software Development. After exploring how to detect errors early and learn from them, in this entry we explore how technical and internal quality is key to sustaining external quality, why less is more, and how to create a culture where working with quality is not the exception but the norm. In this entry, we explore how this foundational quality is not a luxury but the essential hygiene of a well-crafted software product.
Quality as a Development Accelerator
One of the most widespread beliefs, especially in organizations that haven’t yet adopted Lean approaches, is that working with quality slows down development. It’s assumed that writing tests, automating validations, or refactoring consumes time that could be spent "delivering faster." However, from the perspective of Lean Software Development, this view is not only wrong—it perpetuates waste.
In reality, well-understood quality is an accelerator. When the system is healthy—with reliable automated tests, simple design, and robust processes—every step we take has less friction. The team’s confidence in its ability to change the system grows, feedback is faster, and the cost of change drops dramatically. In other words, we go faster not despite quality, but thanks to it.
This is fully aligned with the Lean principles we've been explaining in this series (poka-yoke, jidoka, kaizen).
Moreover, when the team trusts its system—because it knows that errors are detected in time, that the design allows for easy evolution, and that experiments can be conducted without breaking anything—it dares to innovate, try new ideas, and quickly adapt to what it learns from the user. In short, it enables the continuous delivery of value.
In my experience, teams that invest in quality from the beginning and incorporate it as part of their way of working progress much more steadily, quickly, and with less emotional cost. They don’t have to constantly stop to "fix the system" because they never let it deteriorate. And that’s possible because they understand that quality isn’t inspected at the end—it’s built into every step.
Internal Quality as the Foundation of External Quality
In Lean Software Development, external quality—the one users or clients directly perceive—is a priority. However, to sustain that quality over time, solid internal quality is essential: a well-designed, understandable system that can be maintained and evolved without fear.
Many times, the defects visible to users originate from invisible problems within the system: tightly coupled code, unreliable tests, contextless technical decisions, or fragile processes. These issues not only cause errors, they slow down the team, hinder adaptation to change, and raise the cost of delivering value. They are a silent but very real form of waste.
Lean encourages us to see these structural problems as improvement opportunities (kaizen) and to address them systematically. It's not about “beautifying the code” or following arbitrary rules, but about building a solid technical foundation that reduces everyday friction and enables rapid, confident progress.
We also apply jidoka in this context: when a flaky test, opaque dependency, or hard-to-deploy system blocks progress, we flag it as a system problem, not an individual weakness. We stop, analyze, and improve the technical infrastructure to prevent recurrence. Every small change counts. For example, if a deployment fails repeatedly, we don’t just try again—we investigate the root cause and automate a solution, like a script that checks database availability before deployment.
Moreover, poka-yoke principles also apply to internal quality. Using strong typing, simple design patterns, proper encapsulation, and tools that make the right thing easy to do without constant effort are ways to prevent technical errors and ease system evolution. The easier it is to do the right thing, the less likely it is to introduce debt or accidental errors. For example, using a code linter to catch syntax errors before they reach production, or configuring version control to prevent unreviewed code from being committed.
In summary, internal quality isn’t an end in itself—it’s a means to sustainably ensure external quality. When the system is easy to understand, test, and change, the team can focus on delivering value, learning faster, and better adapting to customer needs. That structural simplicity is what allows us to build with quality—and move fast without breaking things.
Quality is Not Complexity or Sophistication
A common confusion in software engineering is associating quality with technical sophistication. “Beautiful” code, elegant solutions, or complex designs anticipating future needs are often praised. However, from a Lean Software Development perspective, this view is fundamentally flawed. In reality, quality is not a luxury—it is a basic necessity, the fundamental hygiene of a well-built software product.
Lean doesn’t reward unnecessary complexity or overdesign. Quite the opposite: it promotes deliberate simplicity as a way to reduce waste, ease system evolution, and ensure reliability. Quality in this context is not measured by how many design patterns we apply or how "intellectually interesting" the design is, but by how well it solves the current problem with the least effort and risk. It’s like cleanliness in a home: not an ornament, but the minimum necessary for healthy living.
Every line of code we don’t need right now is a potential source of error. It not only adds maintenance cost, but also complicates understanding, slows evolution, and can mislead decisions.
"The best code is no code at all" — Ward Cunningham
From Lean’s perspective, anticipating features that don’t yet exist or designing systems beyond current needs is a form of waste. It’s also a kaizen failure, as it prevents learning and iteration step by step. And it breaks poka-yoke by introducing optional, unvalidated paths not covered by tests. Instead of preventing errors, we’re planting them.
Quality in Lean is built with clear, tested, understandable code, limited to what is strictly necessary. We care about design not to make it more complex, but simpler, safer, and easier to evolve. We rely on tests, continuous feedback, evolutionary design, and constant refactoring to keep the system healthy without falling into the trap of planning the future from the present.
So no: technical beauty or overdesign is not quality. Often, it’s its enemy. Building with quality in Lean is, above all, having the humility to do just enough, do it well, and prepare to improve based on what we learn tomorrow.
Conclusions: Quality as Basic Hygiene
In summary, quality in Lean Software Development is not an optional feature or a sophisticated extra. It is the base, the foundation, the essential hygiene of a sustainable and valuable software product. It’s not about seeking complexity or elegance for their own sake, but about building a system that is clear, simple, tested, and easy to maintain.
Quality is like the air we breathe: we don’t always notice it, but its absence quickly suffocates us. Software without quality is software doomed to fail—full of bugs, hard to change, and expensive to maintain. That’s why investing in quality from the start, and seeing it as an essential practice rather than a luxury, is the best way to ensure long-term success.
Quality is not a bonus—it’s the bare minimum. And simplicity is its best ally.
In the fourth part, we’ll see how collaboration and visibility are also essential to maintain this hygiene and build sustainable quality software.
