I believe that an important aspect of any improvement is the ability to learn from the past. In understanding the experiences of both our successes and failures – and those of others. And so, it is important in looking to look at the reasons why the implementation of successful quality design in the software engineering world is such a rarity. In the hope that we can endeavor to not pursue these same mistakes in our design efforts.
Quality failures occur not as the result of any one thing, but rather as a combination of aspects that do not align or attribute to excellent quality practice. It is often a multitude of things that can lead to the final product not fitting together.
When we release software that has a high number of defects, has poor performance, stability issues, or security vulnerabilities, we often rush to find out how we could’ve missed this during our development cycle and make plans to then spruce up their testing efforts or address immediate technical concerns. But few companies focus on changing their outlook on quality.
Quality is the result of a company culture
Culture and processes will often have an even bigger impact on quality than any testing effort can ever derive. If we only on just an aspect of testing without addressing these other areas, we will likely fail in adequately addressing the quality concerns within a team.
So, what exactly is a poor-quality culture and how can impact the design of your software?
Well, firstly, a poor-quality culture is one where the delivery of a team or company is more focused on delivery, achieving a specific tech goal or simply making money. Now, these goals are not inherently wrong. However, when they are the main drivers of your design, many quality aspects can be pushed aside. Resulting in teams either caring little about the overall quality of the solution or trying to work around the problem with aggressive forms of testing Even though – as you will realize – this is counterintuitive to delivering quality.
Now many companies may say they are focused on software quality and take it seriously, but this is not something you can simply tack on later. To be quality-focused is to drive everything with quality in mind and build your software, processes, and even culture around it. Not something that is easy to do.
Building everything with quality in mind might sound like an obvious thing to do and most companies may even believe they have done it. The reality though is that many companies haven’t fully grasped what quality means or how to build it, leaving them with a false sense of surety in believing all is well. Whereas the reality is there are many potential pitfalls that they may soon face or indeed are tackling already.
This doesn’t mean that your company is necessarily riddled with production defects or poorly performant. However, what it could mean is that there may be issues at scale or in the maintainability of both your software and your teams that are likely to grow over time because you have not taken the right quality approach. Functionality is important but the maintainability and scalability of the software may have an even bigger impact as the usage evolves and the surrounding software evolves. Software is constantly evolving and changing, and you need to design your systems to still deliver on quality despite change and even be able to adapt to it as much as possible.
While quality is the most critical aspect of getting quality right, there are more specific things in how it may impact software that we need to highlight.
The truth is that it's any one thing and the absence of just one thing can cause quality to break down. I will try and provide some simplification of the things that can cause quality in a company to fail and if you’re struggling with quality in your organization, it might be worthwhile looking at these things and collectively changing them.
1) The software is built around the wrong architecture
The foundation of any software system is its core architecture. And too often, when companies or teams are designing the architecture of their software system, they’re more interested in either sticking with a tried and tested approach that they are familiar with or attempting to adopt a cool or exciting technology in the hope of making their software appear progressive. Without fully understanding the purpose of the system and perhaps adopting an architecture that best fits it.
Software is all about solving problems and the architecture should be designed around those solutions and be made fit for the purpose of what it is trying to achieve. Choosing the wrong architecture limits the effectiveness of your solution and will likely result in long-term issues in its quality.
2) Software is not designed with testing or quality in mind
This is easily the most important thing when it comes to creating quality software. Too many companies only think about how a system will be tested, maintained, or even define their release standards only once the code has already been written. This is far too late, and companies and architects should be thinking about these things long before the first line of code has been written.
Trying to address quality when the system is poorly designed will only lead to long-term frustrations and while e some level of quality can still be achieved, the effort to achieve it is likely higher than it needs to be.
3) Testing and automation are brought in too late
It perhaps goes without saying that testing shouldn’t be an afterthought. The quality experts in the team should be engaged as soon as possible and we should not start thinking about how we are going to test a piece of work when it arrives with them, but when we are in fact going to design the solution around what their needs are.
It’s allowing your quality experts enough time to analyze the requirements and identify what needs to be tested and how. And then building the solution that matches that need.
4) We don’t focus enough on testing as a career
Unfortunately, as with many things' software development related, testing has traditionally not been focused on as a career. And while over time this has changed, it still appears surprisingly limited in terms of growth. After all, how many CTOs and CEOs of companies have a background in testing or even understand it? Most tech leads or architects tend to be better developers, yet their knowledge of testing may be limited.
The reason for this is we often promote a strong growth and development pipeline on both the development and analysis sides of the business, but not enough focus is placed on a strong development path for testing. As a result, testers feel the need to go elsewhere for career growth. If we ensure that testers are as valued in business as any other function within the business, we can ensure they are engaged and willing to stay with companies long-term.
5) The software is not testable
Too often companies might design great software that can functionally work but is a nightmare to test. This shouldn’t be a thing anymore, but it is amazing how often it still happens. Testability shouldn’t just be a consideration anymore but should form the foundation of a software’s design. This means code needs to be designed in functions that can be easily automated, that functionality should be built into APIs and stored procedures rather than frontend objects, and where UIs are created, that tags should be specific to the needs of the tester's specifications.
It also means that how data and input flow in and out of code is consistent and specified clearly within the requirements and adhered to. Consistent and standardized design is just as important as reliability and teams need to conform to these standards and not do their own thing.
6) A lack of learning
The aim of any quality team is defect prevention instead of defect detection and correction. Inevitably teams are going to make mistakes along the way, and we are going to build things that don’t quite meet the lofty standards you set for yourselves and your customers. In cases like this, it’s important for teams to take the time out to learn from their mistakes.
I have found in many teams and organizations, often one of the key things lacking is a sufficient attitude towards looking back, understanding why issues occurred, and mitigating them for the future. Instead, many teams just jump to the next sprint or task ahead with the hope that everything will go smoothly next time and end up repeating many of the same errors all over again. A quality-driven team on the other hand is prepared to slow down, take the time to reflect, and focus on getting better and improving as a team before they rush off to their next task.
7) Teams are not incentivized on quality
If you think of what teams and companies will often pride themselves in, it’s in their ability to deliver quickly, the number of lines of code they write, or the innovative solutions of their tech. These are things that drive a lot of people in the tech industry.
Having software with as few defects as possible sounds a lot less cool and unfortunately, the same sentiment often applies to the way teams are measured or even incentivized through personal goals. If you want your team to build quality software, you need to make it a priority and measure this accordingly.
Whether a person is a product owner, developer, analyst, or tester, they should be measured on the quality of their software. I do understand that part of the issue may be that teams do not know how to measure this. I will cover some ideas of how quality can be measured in a team in a later chapter on Developing Models for Quality Maturity.
There is a saying in the performance-driven world that you are what you are measured against, and this certainly applies in the tech space where quality can only effectively be delivered in software when we make it a focus for teams to aspire towards.
8) Process quality gates do not place enough emphasis on quality
At any stage in the software development process, individuals and teams have a definition of what constitutes a definition of done. Although we often don’t think too much about this, a definition of done is just as important as the details of a user story or task itself as it will dictate the measurement by which we determine a person is truly completed with their work and should move onto the next task.
This is where we need to be specific in what is needed from a quality perspective and where we should be placing emphasis on ensuring that every task is performed with the right quality outcome.
I again into detail on quality gates and the definition of done deliverables later in the book.
9) Your leads do not understand quality and testing
It’s difficult to build quality into a system or even test any system appropriately if we don’t fully understand what this entails. Sadly, for all the University degrees out there, not many focus on either of these issues, and as companies, we don’t place enough emphasis on building up the understanding of these areas either. And when the leads in a company, whether technical or not, don’t understand what it takes to build and test quality software, it’s likely they will place much emphasis on it lower down.
If a Product Owner, Tech Lead, or even higher-level manager or CTO aren’t collectively focusing on building quality into a solution upfront, it’s going to be incredibly difficult for a company to get this right later. If you want to build quality software, get experts who can help to train and provide this insight and, if possible, ensure that a quality expert is high enough in the company structure to drive this from the front.
10) You are not budgeting enough money toward quality development and testing
As you will see a lot as you continue going through this book, designing high-quality software is not easy nor cheap. In fact, to do something right takes more effort than to do something quickly and as a result, you need to be prepared to absorb these costs.
And I’m not just referring to monetary here, though this is definitely included, but in sometimes slowing down on your delivery to build things correctly or placing more emphasis on building automated testing systems which are often just as tricky, if not even more complicated than the code they test.
Don’t take it lightly- if you want quality you need to invest in it.
11) Lack of accountability
Now, I am not saying here that teams, or people, should be chastised when they make a mistake. Rather I would encourage teams to be solution-focused than trying to point out errors and find fault with others. What I mean by lack of accountability is that there needs to be clear traceability and guidelines within a team on who is responsible for what. When protocols fail and it’s not clear who is responsible for what, things will fall through the cracks.
This also has the unintended impact of limiting teams' abilities to work cohesively together. As teams will end up looking to place blame elsewhere and not take ownership for certain errors rather than taking ownership and looking to improve from their mistakes.
12) You just don’t see the problem
Ultimately many companies just don’t take software testing and quality seriously enough. They might think they do, but a lack of deliberate focus on it will eventually prove otherwise. Companies that don’t place emphasis on designing software correctly, allowing teams to design it correctly, and investing heavily in the right testing frameworks will inevitably lose out on achieving their goals of designing quality software.
Make a change
Driving quality in any organization and pinpointing the challenges is not as simple as I’ve made it sound. Though I’m pretty sure that you could define many quality issues within any organization into one or several of these categories. Over the rest of this book, I will look into certain aspects of software design, testing, and quality culture to assist in better understanding how you can move from these failures toward a successful quality culture.
Or perhaps you are still a young company or team still in the early phases of development. If that’s the case, then you can get the head start you need to build these principles into your products and teams from the beginning and ensure not just quality in your initial offering, but long-term as well.
As long as we’re prepared to learn from the past to look for better paths in our future. Then we are already making the first step to improvement.