Why software quality is behind on software delivery

Delivering software quickly is important to deliver functionality to end users but this can be conflicting with the quality of the software. A solution can be built in a ‘dirty way’ and be beneficial on the short term but not in the long run. In practice, I see that organizations balance more towards delivery than quality. This blog will explain in 3 reasons why software quality is behind on software delivery.

1 – No clear metrics for software quality

The metrics for delivering software on time are quite clear: There is a certain scope of what needs to be build, a set of user stories, and there is a deadline to deliver it at a certain moment. Nowadays most projects are in done in an agile way so at least there is a software release every month. There may be some discussion over what the exact scope was and the deadline date may be pushed a few days, but the deadline day and release scope are tangible metrics.

But, how do you measure software quality? Although there might be ISO standards out there to do this, quality is always specific to a certain context and organization. Software quality can be broken down in variables but I’ve seen they typically have a personal flavour and they change as different people get involved. If software quality is broken down in too much variables, it’s unworkable. And if it’s a few, it’s too simplistic. Also, there can be objective measures that do not represent software quality in a good way. And when the quality is not as expected, I’ve often seen that the discussion is more about the breakdown of the variables than about the measures. Because of the unclear metrics, the concept of software quality becomes intangible and unworkable. As a consequence, software quality doesn’t really get measured in a structured way.

A colleague once told me that what gets measured, is what starts happening. This striking quote explains why software delivery is better managed than software quality.

2 – Delayed effect of poor software quality

The effect of a late software delivery is visible on the short term: Business and end users are expecting new functionality and fixes to their application. New and better functionality is what the end user is mainly interested in. Imagine you have car trouble, you want your car to be repaired as soon as possible. If a software delivery is not (expected) on time, measures are taken by motivating the build teams to go the extra mile and doing expectation management with stakeholders. Days or weeks before a go-live moment, the delivery responsible wants to assess if the delivery will be going or not.

The effect of poor software quality is typically felt on the long term. Going back to the car trouble example, it’s of less concern to the driver how the car is fixed but that the car was fixed. But if the same car issue pops up two months later, there might be a problem in the way the car was fixed. Typical quality issues I’ve seen that start showing on the long term:

• Implementing small changes to existing components takes more time than needed because of ‘workaround code’ and hardcoded logic. The developer that has to implement the change has to do the rework on the first workaround solution;
• The code is not set up in an understandable way and is not commented, so it’s hard for other (new) developers to understand how the solution works.

Poor software quality is (obviously) most visible to developers who work with the software. It’s less visible to architects, and almost not visible to end users and business. This is why it also takes longer for the issue to be visible and get the required management attention. Because development teams are mainly evaluated on what they deliver and less on how they build it, they have an incentive to rather choose for a short-term than a long-term solution.

3 – The effect of poor software quality isn’t easy to understand

The reasons why software is delivered late are easier to understand. And because software delivery is measured, time is automatically allocated to investigate bottlenecks and possible improvements.

Software is mainly understood well by developers and architects and can be a complex thing, it’s not always easy to investigate how different software components attribute to certain effects. And even when it’s clear to developers, it’s not always easily explained to the business and end users. And because software quality is typically not measured in a structured way, there is less ‘official’ time allocated to investigate the effects.

How to get more focus on software quality

As I explained, software quality is typically behind on software delivery. The metrics of software quality are intangible, the effect is not visible on the short-term and it’s harder to understand the effects of software (quality). However, it’s important to understand and control the way an application is built and to measure quality. It’s very important to really start thinking about measuring software quality from the start of a project and not half-way. Make sure these quality metrics are agreed and supported in your organization.