How do you build high quality software?

By Rich Kent
26.04.2023
Read Time: 2 minutes
TAINA technology, Quality software, Software quality, Writing software, Build software product, Building software, Quality first mindset, Software quality tools, Software quality technique, Software quality standards, Software quality processes, High- quality software, software quality mindset, software quality procedures

How do companies build high quality software?

I have worked for many different businesses and have seen many approaches to writing software in my 26 years of experience. In that time, I have learned two things regarding software quality;

  • Firstly, that most senior managers seem to accept that, just like the sun rises and falls, there will be problems with their software.
  • Secondly, if you can develop genuinely high-quality software then you will create a unique selling point for your business that is nearly impossible to copy!

Some people may read the title to this article and ask: ‘Why bother?’. If you develop a product where you have millions of users, you can receive real-time feedback about any defects, and you can push out updates to all those users quickly. In that scenario you can absolutely take a different approach to quality. In fact, in that scenario when taking time to focus on quality isn’t the best use of resource.  For every other business however, producing high quality software is vitally important and equally hard and thus requires a software quality mindset.

 

The 8 Steps to developing a Quality-First Software Mindset

Writing high quality software is primarily a mindset, not a series of processes, procedures, tools, or techniques. There are many good articles written on tools or processes for writing software, however in order to write great software you need to have a certain quality first mindset first.  The points below reflect that, and only the first item relates to process.

If implemented correctly, the following points will help you build software products that your competitors will struggle to compete with. In my experience, software is often written poorly, but quality can, and should be, a unique selling point. 

 

1. Shift Left – All the Way Left!

A good percentage of development teams won’t really think about software quality until the developer’s hand over their software to the test/QA teams.  ‘Shift Left’ is a concept whereby software quality is important not just at the end, but from the very start of the software development lifecycle. A quality focus is ‘shifted left’, or earlier, in the process. Quality conversations should start at prioritisation or planning stages.

 Examples of shift left practices include considering not just what capacity your development team has, but what capacity your QA team has in order to test the software properly.  Quality is then discussed at length when writing the user stories and deciding how to feed work into the development team. The QA team should be actively involved in the development process from the outset, not as a poor cousin at the end.

‘Shift left’ is an important concept and I would encourage you to do further research and adopt as many of its practices as possible.

 

2. Engage Your Customers Regarding a Quality-First Approach

I have seen software delivered to a customer before it was ready so many times. As a result that software comes back to be fixed, with customer satisfaction hitting rock bottom!  This is possibly the hardest change to make, but never, ever release software until it is ready, even if you have committed to timescales with a customer.

Customers will not be happy with a delay to an agreed milestone, but I can assure you that they will be far more upset when there are time consuming issues to address after delivery. If software is not ready, simply do not release it. Always be honest with your customers, bringing them into the conversation early.

In my experience, customers appreciate honesty and this quality first approach.

 

3. Encourage the Team to Get Frustrated When There Are Problems

Software defects are a fact of life, and no developer creates a defect on purpose. When there are problems then it is important for the team to care about it. It is OK to get frustrated and angry about finding problems, so long as the whole team thinks this way, and so long as that emotion is dealt with in a positive manner.

The team should care enough to find the root cause of the problem themselves and to make whatever root cause changes are needed to avoid the same issue happening again.

Creating a blame free culture is important for helping your team adopt the quality mindset and seeing it work properly.

 

4. Measure Quality, Reflect and Learn from Mistakes

Being able to assess the quality of your software accurately and objectively is vital, but reflecting on the quality standards and learning from any mistakes is more important.

Creating a learning culture is the best way to avoid the same software quality mistakes happening time and time again.  If certain software quality processes or procedures do not work, then the team should reflect on them and be free to make changes they decide appropriate.

 

5. Devolve Responsibility for Quality to the Team

It is quite common to see senior managers try to own and control the software development lifecycle process. However the team responsible for delivery are much closer to the action then any senior manager.

In my experience the best software quality comes when you give the team responsible for delivering that software total control over process.

If the software delivery team do reflect and learn correctly then they will be able to fix problems in the delivery lifecycle process faster and more effectively than any senior manager.

 

6. Don’t Forget the Data!

There are typically two types of software issues – logic problems and data related problems. Logic problems tend to be found quickly and earlier in the delivery cycle. Most quality problems relate to data, especially in more sophisticated systems.

I am generalising here, but developers are often optimists, and it is not uncommon to see them assume the system will, of course, be configured correctly.  In practice though data is often poor quality, settings will be mis-configured or forgotten, users will do silly things! 

The difference between average software and high-quality software is the extent to which the software is resilient when the data or configuration of the software is incorrect, missing or outside of expected parameters.

 

7. Hire the Right Type of Person

Having people in your technical team, be that Business Analysts, Developers, Testers, etc., that have the right mindset and personality to work in a quality first environment is not always easy.

Many Developers, for example, really do not understand the importance of software quality and just want to push software out the door so they can move onto the next cool thing. Finding people who will take their time, or at least care enough, is a critical piece of the quality jigsaw. I often look favourably upon Developers who started out their career in QA when recruiting.

Take your time when building your team and ensure you fill it with the people who have the right quality mindset.

 

8. Ensure Your Senior Management Support Quality-First

You can have the best Developers or best QA team, but delivering high quality software requires that your Senior Management genuinely buy into the quality first mindset. I have seen it so many times where the Executive team says the right things, but when push comes to shove then the direction comes to deliver the software regardless so that deadlines are hit.

It really is important to educate your management team on the benefits and importance of software quality, and to ensure you have a genuine commitment to this quality first mindset.

 

How does TAINA build high quality software?

Delivering high quality software repeatedly is not easy, in fact it is one of the hardest challenges in the field of software development. TAINA clients expect a level of confidence in every delivery TAINA makes of its software, therefore it is crucial that we can meet and ideally exceed that expectation.

Every time we introduce a new feature or the software is upgraded, TAINA executes a series of tests including Beta testing, User Acceptance Testing (UAT) and Regression testing to prove our product will function as expected. In fact, TAINA has created a comprehensive regression pack that tests over 2,000 use cases.

However, creating repetitive testing processes to ensure we are confident in our product is only one-step. At TAINA we have found that writing high quality software products requires a certain culture to exist. It is about everyone on the team having the right mindset and not only about a series of processes. At TAINA we believe that if you can achieve the goal of creating exceptional quality software, then you will have a unique selling point which your other suppliers will struggle to compete with.

For more information on how our team is using a software quality mindset to develop out fully automated FATCA and CRS Validation platform, get in touch or request a demo to see it in action.

Whitepapers & Case Studies
Read More +
Webcasts & Videos
Read More +
News & Podcasts
Read More +