Principles shape us.
And when under pressure, our survival mechanism will make us rely on the underlying consequences of our principles.
That behavior is good in itself – but issues arise when invalid principles make us take the wrong decision, even more under the constraint of time.
And in today’s fast-paced environment, the pressure of rapid decision-making is everywhere when software delivery must accelerate.
From balancing speed with quality, limiting work in progress instead of trying to do too much to help the company, software contradictions must be mastered.
This article describes five principles of software engineering to overcome the dilemma of “Quality vs Speed” to build better software faster.
Less is More
Our culture of activity and busyness revolves around the perception that hard work is better than working less, and will lead to better results.
I even admit that I am—or was—a much firm believer of that.
But when you look at successful individuals and organizations, they repeatedly:
- Focus on the minimal impactful things
- Make strong choices of what not doing
- Have strong principles to pursue opportunities or not.
The Less is more principle is powerful as it forces us to focus on what can provide most of the value—and avoid doing the rest.
Examples range from a start-up scaling to millions of users solving one narrowed problem, or larger companies taking strong focus per phase. For instance, Apple with the iPod, then the iPhone, iPad, and then focused mainly on accessories to build the brand lifestyle.
Applying that principles in software engineering can be done with:
- Using Pareto analysis to identify 20% efforts producing 80% of the results
- Implement a technology portfolio and tech radar to simplify the tech stack
- Reduce the work-in-progress challenging better expected returns
- Analyze features-usage and remove the one under a minimal ratio
- Write better and less code requiring less comments.
At a broader level, Less is more is to prefer the minimal practices to develop the business, instead of more fashionable and visible ones—as defended in MAMOS, the Quality Engineering maturity model.
The Old is New
The current pace of innovation, especially in the field of technology, can make us feel that disruptive solutions are appearing everyday.
But most of the innovation is incrementally built on proven models.
“Innovation is taking two things that exist and putting them together in a new way.“—Tom Freston
Take most of the buzzwords shared in the software industry:
- Cloud is on-premise infrastructure made self-service and scalable
- Software-defined networks are built on the historical 7 network layers
- Many quality practices are based on Deming or Toyota practices
- The list goes on (including for Chatgpt).
The point is not to say that there are no changes –incremental and disruptive innovation is happening, changing the state of the industry.
The point is to understand what’s behind the marketing smog:
- Which proven technologies were leveraged?
- Which requirements are needed for the promise to work?
- What’s the likelihood of the innovation to stick, or be replaced?
Our value is to correctly assess potential opportunities, first doing our homework to make sure we master the foundations of proposed solutions.
Then it’s a question of being strong enough in applying the previous principle of Less in More to retain only the most valuable options.
Slow is Fast
A fable by Jean De La Fontaine shares the story of a race between a turtle and a lièvre where, surprisingly, the turtle wins.
The same surprise happens in the software industry.
Going too fast usually means losing energy in the long run due to:
- A lack of engagement and support of key stakeholders
- Missing budget, resources, and a team to deliver early wins
- Superficial changes where the system go back to its initial state
- Implement complex practices that can’t be supported by the organization
- Failure to embark the organization in sustaining changes.
Speed is the consequence of making the right choices in the place, minimizing efforts to what will have most impacts leveraging mature practices.
“Nothing in life is as important as you think it is when you are thinking about it.”―Daniel Kahneman, Thinking, Fast and Slow
In our culture pushing more and more for the short-term, having that long-term perspective and delayed feedback of sustained efforts will be more rare – and also more differentiating when it comes to building software.
You Can’t Test Quality
Shortcuts are dangerous, and the one between testing and quality have already let a lot of deceptions in organizations.
It comes back to starts by the fundamentals:
- Testing is an act of verification
- Quality is about satisfying defined attributes
And considering that companies need maximal quality with minimal testing:
- Quality attributes can’t be all verified – due to constraints like complexity, resources availability, or feasibility
- More testing means more verifications – but not more quality, especially in the earlier stage of the software lifecycle.
“You can not inspect quality into a product.”—Harold F. Dodge
Our responsibility is to foster an ecosystem where quality attributes are defined and part of the software production imperative as a first-class citizen. It’s then a question of leveraging testing with a minimalistic approach to verify where most adequate that quality attributes are satisfied, as fast as possible.
That requires a paradigm shift.
Build Better, Build Faster
Quality Engineering represents the change of mindset towards the historical contradiction of “Quality vs. Speed” faced by so many software teams.
That paradox seems to have no right answer as:
- Quality alone slows down the organization to remain competitive
- Speed alone accumulates technical debt that fails equally in the mid-term.
The paradigm shift is that “Quality enables Speed”.
By deploying the minimal set of practices on the entire software system, quality supports faster cycles of iteration as things can flow with minimal complexity and ease of changing software.
From there, progressive, systemic, and scalable practices are implemented following the maturity model, applying the principle of “Build Better, Build Faster” to deliver Quality at Speed software.
Ready for Quality Engineering?
Daniel Kahneman, Thinking, Fast and Slow. New York :Farrar, Straus and Giroux, 2011.
Susanne Kaiser (2022), Architecture for Flow with Wardley Mapping, DDD, and Team Topologies. InfoQ.
Antoine Craske, Rémi Dewitte (2022), On Defining Quality Engineering, QE Unit.