Managing quality: aiming for excellence

Delivering great software on time for our customers comes down to effectively managing four key elements: scope, risk, quality, and talented people. In this series of articles, which accompany our Tech Talks video, we take a closer look at each one individually.

Here, we tackle the essential topic of ensuring quality…

It’s easy to fall into a trap when it comes to managing the quality of software: an over-reliance on quality assurance (QA) at the end of the process.

While QA is vital, we strongly believe that quality is pervasive, and there needs to be a constant focus on this throughout a project. That also means always paying attention to a customer’s or user’s requirements. After all, there’s no point in building the best product if it doesn’t do what’s needed.

Because we always take this approach, we believe that quality is everyone’s responsibility all the time – from the developers writing the code, to the project managers, and even the customers we’re working with.

Doing this is not easy, and it requires a high level of commitment. But by operating in this way, as a single team, we can deliver outstanding outcomes together. Here are some of the most important considerations we always keep in mind when it comes to ensuring we create great software.

Understanding from the outset what ‘good’ looks like

Quality starts at the very beginning. That means the first discussion with the main stakeholders and really understanding their requirements. We then need to ensure the requirements are described in a way that’s testable, so we can validate whether the finished product meets the correct criteria.

We’ll then work with our development teams to check the written requirements are achievable and can be implemented with the right level of quality. Only once everyone is satisfied with this will we be ready to start work on a product.

Managing time pressures

It’s rare to have a project without some kind of time pressure – and of course that can compromise quality if not managed properly. So, as well as defining ‘Ready’ before we start a piece of work, we also create an agreed definition of ‘Done’. This will include the types of tests and reviews which must be completed before a feature is considered finished.

But, of course, unforeseen problems or scope changes do happen during a project, meaning that things can take longer than expected or need to be reprioritised. When this happens, it’s important to be open and transparent, and also to have courage – for example to explain to a key stakeholder that a change in the delivery schedule might be necessary.

I’ve seen organisations that have a very top-down way of working where people are too afraid to give bad news to their superiors, so they’ll do whatever is expedient to avoid it. Unfortunately, though, the upshot is usually that the management will eventually discover that the delivered product is not good enough – and they’ll wonder why. The answer, of course, is because of the culture in their business. Therefore, transparency and honesty are vital. After all, everyone is ultimately working to achieve the same goals.

Rigorous testing – after every small step

Although, as we’ve stressed, quality needs to be baked in right through the process, effective testing is still crucial. And it’s important to test early and regularly, otherwise a nasty shock may arise at the end – for example, realising an entire project is built on code that doesn’t work properly.

We use agile processes, breaking a project down into sprints that usually last two weeks. At the end of each sprint, we’ll carry out tests to ensure the software is fulfilling its requirements, working effectively, and conforms to the highest security standards.

We employ tooling to continuously conduct vulnerability testing and ensure software complies with OWASP Top 10 security standards. We put these tools into the build pipeline to ensure they are always running and developers know immediately when code is non-conformant.

We also use static code analysis tools to ensure the code we produce conforms to quality, reliability and maintenance standards.

And while our most experienced, senior developers are involved in these processes, again we also look to automate as much of it as possible. That way, a test can be rerun on a frequent basis – as software will always change during an agile development process – with no backlog building up.

Scalability and future-proofing

Scaling needs to be considered from the get-go – but there’s always a balance to be found. It’s easy to end up over-engineering a product so it can scale when that may not be needed for several years, if at all. But ignoring scalability can lead to its own problems if it turns out to be necessary.

It’s therefore essential for us to truly understand our customer’s needs so we can ensure the right level of scalability is built in. We’re also finding that public cloud gives us the option of scaling a product easily and rapidly, if required.

In addition, it’s crucial to consider the future maintainability of a solution – and this is often more important than the initial cycle of development. If quality is compromised during the build phase, maybe for cost reasons, it can quickly become a false economy as maintenance of poor software can be expensive and greatly increase the total expenditure.

In our opinion, automation is definitely the way to go when it comes to maintenance. But it’s incredibly hard to automate if the product hasn’t been built to high standards in the first instance – which further emphasises the need for stringent quality control during the initial build phase.

If you’d like to find out more about any of the points raised in this article, and how we can deliver great software for your business, get in touch now.

Iain Bishop, founder and CEO, Damilah